Comment by WD-42
1 day ago
I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value. You won’t see it right away which is probably where this sentiment is coming from, but it will absolutely catch up to you.
Elegant code isn’t just for looks. It’s code that can still adapt weeks, months, years after it has shipped and created “business value”.
It's a trade-off. The gnarly thing is that you're trading immediate benefits for higher maintenance costs and decreased reliability over time, which makes it a tempting one to keep taking. Sure, there will be negative business value, but later, and right now you can look good by landing the features quicker. It's FAFO with potentially many reporting quarters between the FA and the FO.
This trade-off predates LLMs by decades. I've been fortunate to have a good and fruitful career being the person companies hire when they're running out of road down which to kick the can, so my opinion there may not be universal, mind you.
Sometimes "elegance" just makes shit hard to read.
Write boring code[0], don't go for elegance or cool language features. Be as boring and simple as possible, repeat yourself if it makes the flow clearer than extracting an operation to a common library or function.
This is the code that "adapts" and can be fixed 3 years after the elegant coder has left for another greenfield unicorn where they can use the latest paradigms.
[0] https://berthub.eu/articles/posts/on-long-term-software-deve...
People sometimes conflate inelegance with buggy code, where the market fit and value matter more than code elegance. Bugs still are not acceptable even in your MVP. Actually I think buggy software especially if those bugs destroy user experience, will kill products. It’s not 2010 anymore. There are a lot of less buggy software out there and attention spans are narrower than before.
edit: typo
> I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value.
That's a rather short-sighted opinion. Ask yourself how "inelegant code" find it's way into a codebase, even with working code review processes.
The answer more often than not is what's typically referred to as tech debt driven development. Meaning, sometimes a hacky solution with glaring failure modes left unaddressed is all it takes to deliver a major feature in a short development cycle. Once the feature is out, it becomes less pressing to pay off that tech debt because the risk was already assumed and the business value was already created.
Later you stumble upon a weird bug in your hacky solution. Is that bug negative business value?
You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite.
Look at e.g. facebook. That site has not shipped a feature in years and every time they ship something it takes years to make it stable again. A year or so ago facebook recognized that decades of fighting abuse led them nowhere and instead of fixing the technical side they just modified policies to openly allow fake accounts :D Facebook is 99% moltbook bot-to-bot trafic at this point and they cannot do anything about it. Ironically, this is a good argument against code quality: if you manage to become large enough to become a monopoly, you can afford to fix tech debt later. In reality, there is one unicorn for every ten thousand of startups that crumbled under their own technical debt.
> You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite.
I don't think you fully grasp the issue you're discussing. Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.
The calling card of junior developers is looking at a project and complaining it's shit. Competent engineers understand tradeoffs and the importance of creating and managing technical debt.
1 reply →
Of course a bug is negative business value. Perhaps the benefit of shipping faster was worth the cost of introducing bugs, but that doesn't make it not a cost.
If a bug is present but there is no one who encounters it, is it negative business value?
4 replies →
Perhaps this was never actually true. Did anyone do an A/B test with messy code vs beautiful code?