Somehow code quality has become a topic completely divorced from product quality.
Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
They do care about bugs and new features though, and bad code quality will lead you to more bugs and slower shipping of features in the medium/long run. At least, that's how I define good code.
That's also pretty much the only hope of getting product buy-in on this kind of thing, showing that "no really, there was this particular customer impact". Or "by doing this upgrade in a timely manner, we're not screwed by no longer being able to buy old hardware because new kernels/libraries support the modern replacements"...
The customers are unhappy. I am unhappy. Everyone is unhappy.
I prefer "messy" simple code that works and is easy to understand. Yeah sure I put too much logic into the controller. I could put it into a dozen different files. Fight me.
Copying and pasting a line of code can become a future bug when someone doesn't refactor a line of code. But building some overwrought framework to avoid ever repeating anything can introduce classes of bugs that are much much harder to solve because of the layers of indirection.
And depending on what vertical you're in, sometimes releasing something is the best path to a more reliable app. If you're writing crud apps where 99% of the complexity is defined by business rules, getting a V1 out so you can learn all the places where the business rules were improperly captured gets you a better result than bikeshedding endlessly about having the most polished version of those broken assumptions.
tl;dr: sometimes "worse code" leads to a legitimately better end product for your users.
The development of an engineer:
1. newbie - follow the rules because you're told to
2. master - follow the rules because you understand them
3. guru - break the rules because your knowledge transcends them
I often see code that follows the rules right into a swamp. Your example is a fine illustration of this.
If the thing being written is not going to be updated at all, then, sure, quality is not important.
Yeah they “got it done” but we spend 80% of our time fighting fires and the 20% left on new development takes ten times longer than it ought to because zero thought or care was put into anything other than “it works for me”.
This to me is the difference between engineers and programmers. Programmers can get something done and out the door, but engineers can build something that is easy to iterate on and easy to reason about.
I mean, then they weren't good engineers? Nobody said that approach is good.
But I've also seen enough for my share of engineers that knowingly write buggy code that eventually blows up in someone's face because that code was simpler and turned out elegant that way. Code simplicity and reality don't always go hand in hand. The startup graveyard is filled with businesses with otherwise great engineers that lost sight of the customer's actual experience.
In my experience, that happens way more often than teams failing to produce value because they’ve spent eons polishing something to perfection.
On the other hand, our industry’s culture of not taking the time for anything to be built a little better means we have an enormous number of seemingly-experienced engineers who lack the understanding of how to write well-built software even if they are given the time. Which leads to individuals concluding that time spent cleaning things up is a waste because they end up with something worse and more complicated afterward. So they don’t invest in learning this skill, and the cycle repeats.
I wish we had someone doing that with code.