Recently, I was pondering why it is that programmers and employers have different attitudes toward the quality of the projects they collaborate on. I formulated it like this:
Dismissing quality concerns early may cause breaks and stoppage when the product is more visible or closer to deadline, thus leading to greater stress and strain to get work done under increasing public scrutiny. The programmer blames the lack of quality for the troubles, and the employer laments the programmer’s inability to work as quickly as he did earlier in the project.
Two Different Definitions
While the above analysis may be true, I realized later that I was approaching the problem from the wrong angle. It’s not that one cares more about quality than the other. Instead, it is that they have two different definitions regarding project quality.
The programmer’s “quality” relates to the what he sees and works with regularly and is responsible for over time (the code itself).
The payer’s “quality” relates to the what he and the customers see and work with regularly and are responsible for over time (what is produced by running the code; i.e., the product, not the program).
That’s the source of the disconnect. When approached in this way, “quality” as judged in one view is now obviously not the same thing as when judged in the other view; code quality and product quality are distinct from each other (although still related).
One interesting point is that the developer has some idea about the product quality (he has to use the product in some fashion while building it), but the manager/employer/payer has almost no idea about the code quality (they are probably not writing any code).
The solution to the disconnect in software development may be to involve someone who understands both sets of concerns, and who has the authority to push back against both sides as needed. Then the business as a whole can address the concerns of both sets of people.
1. Thanks to Brandon Savage for reading and commenting on an earlier version of this article.
2. Incidentally, I think the “quality” definition disconnect also applies to various non-software crafts and trades. You hear about carpenters, plumbers, painters, etc. complaining that they get undercut on prices by low-cost labor who don’t have the same level of quality. And yet the customers who choose the lower-cost option are satisfied with the quality level, given their resource constraints. The developer-craftsman laments the low quality of the work, but the payer-customer just wants something fixed quickly at a low cost.