Software engineers hate code

What I hate is inconsistency. Inconsistency is what makes code intolerable to work with, because changing it becomes so much harder.

Consistency, in the way I mean it, does not mean DRY or over-abstraction. What I mean is, pick a mindset or design philosophy and stick to it. Don’t randomly switch between exceptions and returning errors. Don’t over-abstract some areas early on and then spaghetti code other areas. Have some consistency in how you do this.

For example, have a rough standard for when something is X or Y. Either accept spaghetti code for areas and keep things uncoupled as much as possible (my preferred), or have some concept of abstraction you apply to new layers. Just rough examples.

If it turns out you did it wrong, which is likely, then it is relatively easy to reason about a change. But as soon as you lose the consistency then it becomes a nightmare. Don’t have special snowflakes in your code.

The last thing I’ll write is.. sometimes the over-generalization this article makes is used as a weapon to justify sunk cost fallacy. Sometimes throwing away a part of your codebase and starting from scratch is the best thing to do. But you should work with it for a bit to understand the code before doing so.

Any business that employs software developers knows exactly how much it costs to employ them. If that math doesn’t work then the software developers loose their jobs. This basically establishes a baseline for “value” that must be delivered, at minimum.

Above the baseline, software devs are left to their own devices: There will be no hard accounting of weather development effort is “worth it”, rather it’ll mostly be about whether people feel like it was. (This is sort of the origin of “too much money spoils things”.) As long as the effort doesn’t destroy everything, it can be argued that it was a success!

So, the “hidden” costs are actually “bearable costs” because the business is just fine. The costs are “revealed” only when they’re no longer bearable. Ironically, well designed software “hides” the costs much longer than poorly designed, so what is missing is that we don’t have a great way of assigning value to in-house developed software that “just works”. Developers don’t even really think about it much because they get paid for writing code.

I think that’s why the advice…

> Use what already exists

… becomes very hard, in practice, for devs to follow, even though it’s excellent advice. It’s a problem for management to solve.

A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios.

So, “this code works” is really a range, not a binary condition.

None of that has anything to do with "Time thinking about the problem", nor does either one imply that its questions are easier or harder to answer in all scenarios. They're just very different questions, but some devs prefer dealing with the issues a greenfield project presents.

Or if the old system simply doesn't work with modern environments.

Or if it depends on long abandoned frameworks.

Or if the business grows but the old implementation scales badly or not at all.

Or if it depends on components that incur licensing fees that become prohibitively expensive when it's scaled up.

Or if there are other legacy systems on different technical baselines that it could work with better after being rebuilt on the same base.

Or if its tech simply requires more maintenance than an alternative, thus binding dev resources the company could otherwise use more productively.

There are alot of reasons why maintaining an old system may be an undesireable move in the long run, that have exactly zero to do with the competence of the developers involved.