First off, I love beautiful code and have been known to fixate on it so this article is a formalization of what I think to myself every time I start to get religious over coding quality.
Code quality is an oft talked about yet poorly defined topic amongst programmers. Ask 100 different developers what "quality" means to them and you'll receive 100 different answers. Responses will range from "Quality code is code that can be easily changed and understood" to "Quality code is hard to define but following the SOLID principles is a good start" to "it's more of an art that's hard to define." Ok, but maybe you're thinking that these are too abstract and should refer to reducing costs and reducing bugs. Sure. Maybe. Ultimately, however, all of these definitions of "quality" skirt the elephant in the room.
On commercial projects, high quality code will help enable my company to maximize its profits.
When I get in a heavy debate over whether or not someone is really "unit" testing or just "integration" testing, nowadays I ask myself (and then my sparring partner) "Is this why we can't deliver software?" Put another way, "Is this the most critical obstacle in the path of my company making more money over the short and long term?" The answer is usually no.
When it is no, I have to suck up my ego and walk away from the discussion since I've admitted there's limited value to be had. Note, there's some value, especially if my purpose is getting on the same page as my team.
When the answer is yes, as it oh so very rarely is, now I can make a bold statement if I can concretely share WHY this is more seriously affecting the performance of the company over every other concern. Here's an example:
Imaginary dev: "I don't have time for automated testing so get off my back about it."
Me: "Automated testing is the single most critical thing we can be doing to drive our company's profit because every bug we miss is a bug our customers have to catch and their time is so limited that they cant possibly catch them all. That means the bugs will make it to our customers who will slowly lose faith in our product with every issue they find. We can't afford to manually test so we absolutely have to run automated tests."
While perhaps not bullet proof, that's a strong argument. What would an even stronger counter argument look like?
Imaginary dev: "If I can do what's worked for me in the past and just get this feature done by this hard deadline our customer will pay us a $3 million bonus. Our business customers have already decided and agree that even if we do nothing but review the code I have written for two weeks after the deadline, it will still have been extremely profitable for us to take this measured risk."
Do you believe in "quality" so much that you would ask your team to not let one of the devs on the team you've seen consistently pull in results to bring in a $3 million pay day? If you do, what's your number? If you don't have one, then you're not in this business for the business.
Hi, my name is Justin. I'm a recovering code wanker.