Paul M. Jones

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:

• The people who do the work are usually the ones who care more about quality. Why?

  • They have a reputation to maintain. Low quality for their kind of work is bad for reputation among their peers. Note that their peers are not necessarily their employers.

  • They understand they may be working on the same project later; higher quality means easier work later, although at the expense of (harder? more?) work now.

• The people who are paying for the work care much less about quality. Why?

  • The reputation of the payer is not dependent on how the work is done, only that the work is done, and in a way that can be presented to customers. Note that the customers are mostly not the programmer’s peers.

  • They have a desire to pay as little as possible in return for as much as possible. “Quality” generally is more costly (both in time and in finances) in earlier stages, when resources are generally lowest or least certain to be forthcoming.

  • As a corollary, since the people paying for the work are not doing the work, it is easier to dismiss concerns about “quality”. Resources conserved earlier (both in time and money) means greater resources available later.

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.