Quality Last: Why We Make Poor Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
~Dr. Lasting Evil
Chief Executive
Shoddy Products That Cost Less Money, Inc.
Sounds like a great corporate mission statement, does it not?
As silly as it sounds, the above is the basic business model for many technology companies, consulting companies, and internal technology groups. The software craftsmanship movement is doing everything it can to renew focus on the importance of quality software, but until we find a way to make software quality a contractual obligation, quality will always lose.
In the End, It's What Was Signed on the Dotted Line
Are we really all like our fictional Dr. Evil, purposefully trying to make poor-quality software that hobbles businesses with levels of technical debt that would make a maxed-out credit card look like an accounting error? I don't think so. I think that most people in the business of software delivery—developers, project managers, or any other title—want to deliver high-quality projects that make a positive economic impact.
The problem isn't that we don't have good enough intentions. To get at the root of the issue, you have to start looking at the language that controls how developers ultimately get paid. (When conditions of payment for a given project depend on everything but quality, it's usually not hard to guess what happens when crunch time hits.) In technology consulting, and even in many internal IT departments that have implemented internal chargeback systems, the language of control begins in the Statement of Work—the main contract that defines the legal terms and conditions under which a project operates. This document often references what features a given piece of software will have (sometimes with mind-boggling levels of detail).
In some contracts, the Statement of Work references who will staff some or all of the roles for executing the project. Pretty much without exception, the two most notable items on a Statement of Work are duration and total cost. Noticeably absent from any language in the Statement of Work is anything about required level of quality, particularly quality of source code delivered. As a result, unless extraordinary effort is expended to ensure that the software is of the requisite level of quality, the forces of economic inertia will dictate that, all other things being equal, quality will lose.