By Jack Ganssle

Quality Software

Published 10/30/2006

In it he defines six quality principles and metrics for evaluating them. The first is the most important: If a customer does not demand a quality product, he or she will probably not get one.

As I mentioned in this column last week (and I'm writing this before the results of the November 7 election), in my opinion the reason e-voting machines have performed so poorly in the past is that the FEC and local jurisdictions don't demand a measurable level of quality that's audited and verified. Nancy Reagan admonished youngsters to "Just say no," a command just as advisable for state elections officials. If the product doesn't meet standards, just say no. Reject it.

That's important for all software acquisition and internal development. Set measurable and realistic quality goals and demand the product meets those goals. Simply do not tolerate software that doesn't meet the bar.

These quality maxims are the guiding principles behind Mr. Humphrey's Personal Software Process (PSP). He was one of the architects of the well-known Capability Maturity Model (CMM), used by some big companies to control software projects. The CMM is the heaviest of the heavyweight processes; it's hugely expensive to implement, and is thus not practical for most organizations.

But Humphrey asked an interesting and profound question: "What can I do to change the way I write code so it's measurably better, without getting approval or funding from management?" The PSP is the result. It's a formal set of strategies that leads to better code. Incidentally, programs created using the PSP are cheaper than those from programmers working without a process. Better and cheaper - works for me!

His book, "A discipline for Software Engineering" spells the process out. It's a textbook, though. Remember those? It has homework. Remember that? Don't do the homework and you'll get no benefit. The homework isn't easy, either. You're expected to write code and collect a lot of statistics, and then analyze those. The open source PSP Dashboard (http://processdash.sourceforge.net/) can automate much of the tedium.

PSP sounds like big process but it isn't. Many have integrated its practices with agile methods (for instance, http://csdl2.computer.org/dl/mags/so/2003/03/s3089.pdf but membership in the IEEE Computer Society is required).

It is hard to get high-quality software. But it is possible, and PSP is one well-proven approach. It doesn't take the approval of your boss or any sort of corporate buy-in. It just takes a commitment to quality, and a level of professionalism which seeks better approaches.

Here's my challenge to you: why would you not give up the self-help books for a time and learn the PSP? What's the downside?