Good code is as much about the lines of code you write as the lines of code you don’t write. I find it pretty easy to intuitively differentiate between good code and bad code because it’s something I feel while working with it. How come it is so difficult to explain this to someone who doesn’t intuitively feel it?
An argument could be made that good code is for example loosely coupled or testable or it uses certain design patterns. I can confidently say that I’ve worked in multiple systems that followed these principles and it was still a complete mess to work with. There is more to it than following simple principles, but it is what people tend to fall back to.
I’m aware that no such thing as perfect software exists, but I’m still continuously baffled by the lack of awareness of bad code. I’ve had many conversations about major design flaws and the opinions range from “Does it matter? It works, so it’s fine” to “We’ve designed it according to principle X, so it’s fine”.
Well, yes, but no. I think the problem is this:
A lot of conscious decisions go into writing good software that are not directly reflected in the resulting code.
Just because something works doesn’t mean it’s good and it’s not because you made a design decision, that it’s the right one. Good code is good because of all the alternative design decisions that weren’t taken and therefore all the lines of code that weren’t written. I find it extremely hard to explain this to someone who doesn’t intuitively understand it.
One issue is that the total cost of bad code or design decisions is virtually impossible to measure because there’s no baseline to compare to. You can’t reasonably reimplement everything with an alternative approach and do a side-by-side comparison. This lack of objective data makes it extremely difficult to make a business case, resulting in a lot of decisions based on gut feeling. As a result, the code base can be in pretty bad shape even at tech companies, companies that made writing good software their business.
It would be amazing if Software Engineering could be made into a more objective discipline instead of relying so much on gut feeling.