> Your users don't care how clean your source code is
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.
I have seen people strive for cleanliness from the get go, but that has resulted in garbage outcomes and overabstraction.
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.
yeah, the number of times I've cleaned up some code because it was "just wrong" and as part of making sure it had test coverage for visible impact, identified a "oh, this has been flaky at a customer site for years, but noone had a good angle on it"...
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"...
Chasing code quality and code-quality-adjacent metrics often results in buggy apps.
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.
> 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
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.
I like to say that users includes the people working with (using) your code in the future. It changes the definition of user compared to the normal usage, but I think it's a good point.
Every coworker I’ve had who thinks this way has left a minefield of gotchas and inscrutable interdependencies for the unfortunate developers who come after.
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.
> Every coworker I’ve had who thinks this way has left a minefield of gotchas and inscrutable interdependencies for the unfortunate developers who come after.
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.
It’s also littered with the bodies of companies that failed to keep up with their early initial development speed because their development team cranked out two years’ worth of “whatever works” and walled themselves into a corner.
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.
You are correct that good code does not translate directly into revenue, but it affects it indirectly e.g. through ease of future development, maintenance, and fixes.
If the thing being written is not going to be updated at all, then, sure, quality is not important.
It is worse than them not paying you. "You" (the company) are paying them. That means you want to minimize the amount of time they spend on the software without getting further returns of some sort.
The point I was making was that if your product is good, even if the source code is terrible, you can still keep selling it as-is and keep making money. You won't be able to improve it easily, but at least the current state is producing value. By contrast, if your product is bad, then you're going to miss out on revenue until you fix that, no matter how awesome your codebase is.
Youtube has more than a couple people who pull apart tools and see how they tick, then they speculate on how what they found informs the users' likely experiences with this model over another one.
Your users definitely do, but the signal is usually so attenuated that people can pretend that they're mad about something else other than code quality.
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.