[anononaut]

Complexity and quality can be completely orthogonal. When they aren't, complexity and quality of code are proportional, which is a smell. Readability is often cited in lists of what makes good code, and rightfully so, but it isn't the most important thing. The most important thing is the ETC principle; that the code is easy to change.

You bring up a good point about something that needs to be added NOW, which is a project management/business/cultural concern and something that needs to be addressed. Compromising code quality for speed is a classical trade of and is probably the reason most professional developers on HN hate their projects.

Funny you bring up that example! I do work at a FinTech org and my 2020 was spent working on a trading platform frontend. (Hell of a year...)

[ragona]

I agree that complexity and quality can be unrelated. I think that quality is often misinterpreted as beauty, or brevity, or cleverness — and those are not the same as quality, in my opinion. Often a long function with a bunch of error and edge case handling is seen as ugly, and thus low quality, and what I’m getting at is that an ugly function can also be quite high quality.

And heh yeah it was on my mind because I just spent a few years at a FinTech too — and a lot of that code is incredibly sensitive, and must contain all kinds of “ugly” condition handling that I don’t think is really low quality, it’s just a complicated problem space that requires a ton of attention to detail. And details can be less fun to read, I think we all can get seduced by code golfing and making things prettier, which is again not the same thing as better.

(Which is I think the point of the article — readability and prose is perhaps key in literature, but not always in software.)