[ragona]

I think the problem with this assertion is that over time "good" code often ends up littered with important conditionals to handle cases that upset the general readability and expressiveness of the initial delivery. Imagine a FinTech working on some kind of trading platform. It seems simple and clear at first, but over time more and more safety mechanisms, edge cases, regulatory obligations, and all kinds of other things need to be added -- and often they need to be added _now_, which means that readability is not the primary concern. I think that's the point of the article; readability is often not the most important thing.

I don't think that suddenly catapults the code into "bad" code, and in fact it's this kind of accumulated wisdom that makes full rewrites so famously expensive. The initial core of the idea might be able to be expressed in a simple and beautiful way, but over time it turns out that almost nothing is truly simple, and complexity accumulates. But it's good complexity, it's important to the business, and it doesn't mean that it's bad code.

[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.)

[epgui]

That's a practical design problem, not a fundamentally-necessary evolution of code.

[ragona]

You don’t think handling edge cases and errors is fundamentally necessary?

[dabears]

The real trick is doing both. Code that reads like a short story while including error handling and edge cases. This is achieved in a practical way by first keeping it as simple as possible only implementing strictly necessary abstractions. When the code reaches a "tipping point" then refactor. Rinse and repeat. If the code is structured reasonably that refactor should be mostly limited to the trouble spot.