I used to manage a group of engineers who were very keen on maintaining their standard of software craftsmanship. They had a high test/code ratio and were always up to date on the latest idioms. That was their idea of craftsmanship and something that written standards could easily support.
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).
This whole issue is a sore spot for me. Seems like I've always had someone who missed their deadlines but "cleaned up" something that didn't need cleaning up. I've even done it myself. It's an easy trap to fall into, after all, we tend to be optimizers, maximizers, and perfectionists.
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.
Why not delete code? Old/stale/unused code gets only in the way and doesn't serve any purpose. And if you really happen to need it later, it is readily available in your version control system.
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.
"And if you really happen to need it later, it is readily available in your version control system."
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.
The "don't fix it until it's broken" is an interesting discussion. From what you've said, customers and developers can have a very different definition of what "broken" means, and the customer's definition trumps the developer's. I don't imagine you'd throw out all the refactoring and "cleaning up" jobs though. There'd have to be some consensus case-by-case on what is really broken and what isn't. Managers can overlook some serious code rot just because the front end seems okay. I'm guilty of being the perfectionist though, and it'd be wise of me to keep my pragmatic hat on more often.
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.
Maybe the rule should be "don't fix it unless you're capable." Then you could have some guidelines for when someone is capable. Some of that might have to do with skill/experience but even with my own code I don't like to make fixes unless it's related to a feature I'm in the middle of. Otherwise I'm at risk for making subtle functional changes that I don't have any capacity for understanding or predicting.
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.
This is a new phenomena that is unfortunately gaining a lot of traction in Silicon Valley. I used to work with guys who know and love your guys and all the other guys who have the blogs and the tweets and the meetups and whatnot.
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.
