A couple weeks ago, I posted my response to Joel’s Duct Tape programmer article. In that post, I linked and quoted an article by Casey Charlton which said that quality was a business decision. I started thinking a lot about that statement, and asking myself the question, is quality really a business decision?

If you are a developer, has the business ever asked you to create a 50% quality product? Has the business mandated that functionality not work 10% of the time? Maybe the bubble I live in at Rackspace shields me from businesses like this, but Pat has never told me to sacrifice quality on anything. In fact, he only expects the results of my work to meet his expectations. He never asks me for code coverage, or code complexity, or any other metric trying to determine the quality of the code. He only asks for results.

Maybe the confusion is over the term quality? There is a difference between functional quality and code quality. I can achieve high functional quality with bad code quality. It might not be easy, but I could hire 2 QA people for every developer and probably achieve it.

The business does directly impact functional quality. If the business is creating the functional requirements, meeting those requirements is functional quality. Those requirements could even seem very technical, like scaling to 100M users, but they are still functional requirements.

Now that we understand functional quality is a business decision, whose decision is code quality? It is a pure engineering decision. Based on business requirements and delivery dates, software engineers determine how to achieve results and how much duct tape to use. Don’t believe me? Read Wikipedia’s definition of Software Engineering (no, I didn’t write it and it is cited):

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

The problem is most developers don’t realize this. Instead of trying to achieve both functional and code quality, developers assume a deadline means they should sacrifice code quality. Notice the wording I used, ASSUME. There is no systematic, disciplined, quantifiable approach as to why most developers choose to sacrifice code quality. This is not how engineers are supposed to work.

Think about the parallel of civil engineering. Civil engineers are given a task, like building a bridge. They are also given a budget and timeframe. From there, they determine the materials and methods to use to create a safe structure. They even predicate how long the bridge will last before needing maintenance.

How awesome would it be if software engineers could do the same thing? Software is still such a new practice, we are continually figuring things out, but eventually we will get there. People like Uncle Bob and the Agile Manifesto crew have tried to establish patterns and practices that guide developers based on their experiences.

Quantifying code quality and its impact on functional quality, performance, deadlines, maintainability, and learn-ability is extremely hard. But, we have to strive to understand this information. It will continue to make us better professionals that can reliably accomplish great things.