Quality: Program vs Product


Why it is that programmers and their employers have different attitudes toward the quality of a project? Thinking of myself as a programmer, I have sometimes formulated it like this:

  • The programmers 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 employers 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.

These points are summed up well by Redditor JamesTheHaxor, who says: “Truth is, nobody cares except for us passionate programmers. We can judge a persons skill level based on their code quality. Most clients can’t. They judge a persons skill level by how fast they can get something done for the cheapest price that works to spec. There’s plenty of shoddy coders to fill that market. They always undercut me on freelance sites.”


The problem is that the term “quality” means different things to different people. The in the programmer/employer situation, there are two different definitions of “quality” at play (or two different things that are being paid attention to).

  • The programmer’s “quality” relates to the what he sees and works with regularly and is responsible for over time (i.e., the code itself: the “program”).

  • The employer’s “quality” relates to what he and the customers see and work with regularly and are responsible for over time (i.e., what is produced by running the code: the “product”).

“Quality of program” is not the same thing as “quality of product.” They have different impacts at different times in the project, and have different levels of visibility to different people involved in the project. They do not exist independently of each other, and feed back on each other; change one kind of quality, and the other kind will likewise change.

I think this 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 programmer-craftsman laments the low quality of the work, but the payer-customer just wants something fixed quickly at a low cost.

Dismissing quality concerns of either kind early on 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 code quality for the troubles, and the employer laments the programmer’s inability to work as quickly as he did earlier in the project.

What’s interesting to me is that the programmer 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). So it’s probably up to the programmer to understand the consequences of program quality in terms of product quality.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

One thought on “Quality: Program vs Product

  1. I heard this idea somewhere that technical debt is a *deliberate* decision to do something in a sub-optimal way to meet a short-term goal (often a deadline). For example, a team might choose not to implement a full performance monitoring and reporting sub-system for a website before they launch.

    The giant mess some teams make because they’re in a hurry or don’t know any better is not technical debt–that’s shipping s#^t. And that violates Uncle’s Bob’s first rule of software professionalism (https://youtu.be/BSaAMQVq01E).

    As programmers we’re supposed to be the experts. And I believe it’s our job to effectively communicate the trade-offs of various options and guide our customers/employers to the best solutions possible with the resources available.

    I don’t think anybody wants crappy software. But I suspect many programmers do a lousy job of communicating the trade-offs of cutting particular corners or negotiating alternate courses of action to meet budget or time constraints that won’t cripple the project down the road (or they just give up after a while).

    The cost-quality curve for software is a giant U. It costs lots of money to make crappy software (if you can finish it at all) and it also costs lots of money to make flawless software (think avionics) And the lowest cost software is probably farther to the right on the curve (higher quality) than most projects. So it would actually be cheaper to produce software of higher quality–all things being equal.

    That’s how I sold the idea of quality improvement at my job. I kept pointing out all the messes that were slowing us down and selling my employer on not making it worse. I explained that we plan to operate this software for the foreseeable future so we should take care of it (I also got everybody to read your book: Modernizing Legacy Applications in PHP). It wasn’t an easy sell and we are still struggling to balance the time we spend adding features with the time we spend doing clean-ups, but we are moving forward and nobody is talking about a big rewrite anymore.

    So, yes, it’s up to us to understand the consequences of the program quality in terms of the product quality AND communicate that effectively to decision makers.

Leave a Reply

Your email address will not be published. Required fields are marked *