Only if you don't plan to have employees.
a. I won't have employees or
b. They will follow standards.
Either way, I'll never have the problems in the original article.
We'll be far too busy addressing issues to be arguing over details. I have never tolerated that from employees and I don't imagine I ever will.
However, our customers were complaining bitterly about bugs and missing features. They had a totally different idea of craftsmanship. Certainly our written standards could have been expanded but I found that the core issue was that the engineers had latched on to code quality when our customers really wanted them to latch on to software usefulness. The fault probably lay with the managers, as we couldn't figure out what was the useful thing we wanted to build. Thankfully one of the engineers invented Twitter in his spare time and we were all saved (a simplified but mostly true story).
I actually left my last startup because they hired an engineering manager who was more into test/code ratios and migrating to the latest deployment framework instead of fixing longstanding user complaints. 6 months after I left, the (easy to implement) features our users were complaining about are still not up on the site, and I see job postings looking for a new engineering manager.
The best approach to this I've ever found is the solicit agreement to a few simple rules and standards. Things like:
- Don't fix it unless it's broken.
- Don't delete any code. Ever. (Did I say ever.)
- Don't bypass tools we've agreed to use.
- Don't violate standards we've agreed to follow.
- Quick and dirty isn't quick. It's only dirty.
Often the violator doesn't even realize what he's done until you point it out. OP was obviously a caricature, but you still gotta stay on top of it.
I fully agree with your rule about quick and dirty. I'm currently rewriting a module that was "designed" with the "I just want to get it done" approach to software engineering.
What's the old saying? A few weeks of coding can easily save you 5 minutes of design?
We're also missing a deadline. But what is the point of meeting the deadline if we have to throw out the code afterwards and start over anyway? It is better to do it right the first time. A solid system a few days late beats a crappy system on time.
In my opinion, if the code is so complex and messy that you can't see whether individual pieces are correct, then it must be considered broken, even if it compiles and does something.
Of course. I was referring to code deleted from everything, including the version control system. By the time someone noticed, it wasn't findable even on backups. Believe it or not, in some shops it does happen.
I'm a little wary of code standards. I've found that they can be a bag full of cargo-culted banalities like "never use break statements", "never have more than one return statement", "the tertiary operator is the spawn of the Devil", "if you use a one-liner if-statement you will hang", or "duplicate all of the version control history by hand at the top of every file". I'd feel much more comfortable if I worked in a small team and we all got together and agreed on some important and useful standards rather than have them dictated by a manager who used to code back in the 90s.
And more importantly. Every standard is meant to be broken. It's just supposed to make you think about why you're breaking the standard. Cost-benefit and all that jazz.