"Successful software products can be built from mediocre (or even bad) code."
If you've been in the industry for more than a few years, you've almost certainly seen it: source code so bad that entire websites have been created to showcase its horror - and yet the product created from that source code is sold by someone, bought by someone, loved (or at least tolerated) by some users, and is generating a profit for some company. I wish I was wrong about this, but it seems undeniably true.
"A commitment to high-quality code has tangible upfront costs, and less-tangible long-term benefits."
It requires a commitment to hiring (and retaining) skilled personnel, and resisting the urge to just throw something together any-which-way, in order to get it done faster. The benefits come later (and more theoretically), in the form of fewer bugs, faster product enhancements, faster ramp-up for new employees, etc.
"Companies want mediocre code."
That's not precisely true: companies want the benefits of high-quality code - but they aren't willing to pay the costs. They want to be able to hire mediocre people, and offer them mediocre compensation. They want the option to deliver certain functionality by a certain deadline, by throwing code quality out the window, and / or by shoving more and more inexperienced man-hours at the project.
I've come to believe that is the dirty little secret of our industry: the "strive for mediocrity" business model actually works. This is not inherently a bad thing, nor is it a good thing - it is simply business 101: maximize profit. If a sell-able, "good enough" quality product can be produced via mediocre code, why pay the costs of a commitment to high-quality code? There are plenty of developers comfortable working within this paradigm:
- Inexperienced developers not yet able to produce "craftsman-quality" code.
- Ambivalent developers who aren't interested in learning to produce "craftsman-quality" code.
- Pragmatic developers who can produce "craftsman-quality" code, but are comfortable with the fact that much of the time they won't be allowed to. These people will be the true MVPs of a company's development team - able to focus on the end-product (regardless of underlying code quality), and with the skills to make it happen.
Thus, it's time for me to leave the industry - a love of and dedication to well-crafted code doesn't really fit in with corporate software development. The industry isn't what I'd like it to be; but as I said above, that's not inherently good or bad, it's just business.
I'm glad I went through the time and effort for this blog. Leaving behind 20 years of work and experience is a difficult decision. Doing so based on nothing but a vague feeling of dissatisfaction would have been a stupid decision. But doing so because you know the profession holds nothing more for you except disappointment and frustration, is probably a wise decision. Or at the very least, it's one I can live with.
Edit: a friend pointed out that I missed a category of developer: "mature developer, capable of quality code, but beat down by many years in the business." While these people undeniably exist (quite possibly in large numbers), I don't think they actually fit the description of "developers comfortable working in this paradigm". Nevertheless, they are definitely worth a mention (thanks, Sharon!).
