And the Applicability to Software Is

And the Applicability to Software Is…

I'm sometimes accused of making very general observations under the guise of talking about software development. I plead "not guilty!" It's simply that the principles I believe in are universal, and their value is not limited to the realm of software. On the other hand, I can show why the particular values I've identified are relevant to softwarewhy, unless you observe them, software products and companies degrade.

Let's go back to integrity, one of our basic values: We never lie to our customers, and we never lie to ourselves. We deliver a quality product in exchange for a sum of money, and the customer has a right to expect value for that money. There is nothing specific to software in that simple equation.

Yet the production of a software product that customers will be able to use throughout an extended period requires integrity. First, the product must be sustainable in the field for many release cycles; it can't just be cobbled together for the next release and then forgotten. In order to achieve this, the product must have a maintainable underlying architecture that can be modified over time to suit new, emerging requirements. Also, the product must be supported, so that as questions and defects arise, the organization can cope with them and provide solutions for customers. It takes considerable infrastructure to support and evolve a product during many years, and making that investment requires the integrity of a long-term view. Companies that "ship it and forget it" will not be around for long.

A high-trust environment and teamwork are essential for the production of any large software product. Why? The answer is simple: Software is by nature a very complex product. Many individuals on the team make many thousands of decisions every day; some are large, some are small, and all may have an impact on customers. If we were to depend on a system of permissions and checks to ensure that each and every decision was "correct," progress would grind to a halt. What we need instead is everyone making good decisions on one's own most of the time. Large, critical decisions need to be reviewed, of course, but the majority should be made promptly and implemented effectively and efficiently. This is impossible without integrity at every level of the organization.

Now let's think a little bit more about customer focus. The quality mavens are always getting up on their soapboxes and lecturing us about the need to improve the quality of the software we ship. But it's a bit more complex than that. Quality is a very subjective objective. Some people measure it by defect counts; others talk about usability ("fitness for use" for some, performance for others); still others have different metrics entirely. But none of these can be evaluated in the abstract; there is always, always, a trade-off between quality and some combination of cost and timeliness.

That is why I think customer focus is the right value, and the cultural manifestation of this value is that everyone in the organization thinks about the customer: developers, testers, writers, product managers, support, field technical people, salespeople, marketing folkyes, everyone. The customer is no single group's responsibility; it is everyone's responsibility. If you have both a high-trust environment and everyone focusing on the customers, then you have a potent combination.

And what about results? Well, systems need to be architected, coded, documented, tested along many dimensions, and then built, packaged, and shipped. Without an intense focus on results, the product just doesn't get out the door. Too many things depend on too many other things. The lesson of the old folk tale, "For the want of a nail…"^[10] was never more true than for software development. Most projects slip because of an accumulation of intermediate tasks that are delayed, deferred, or simply not completed. Individually, none of these small slips seems important, but the cascade is devastating.

^[10] The tale starts out with a missing nail leading to a missing horseshoe, then a missing horse, and so onall the way up to losing the battle and the kingdom, "all for want of a horseshoe nail."

On the flip side, there is a hidden danger in striving for "perfect" results in all the details. Everyone needs to be clear on the most important result: timely shipment of a high-quality piece of software. Creating a perfect Software Requirements Specification along the way will be irrelevant if the customer-visible resultthe productis wanting.