email article printer friendly

Of Software and Sherman Tanks
In any team-based endeavor, organization, discipline, and method are the order of the day—programming work is no exception
by Daniel F. Savarese

July 19, 2005

Early in my career, I believed that software development was fundamentally different from other disciplines. That's what the conventional wisdom was saying at the time, both inside and outside of academic circles. Today, I have no qualms asserting that I was too inexperienced to see those claims for the hogwash they were. Insiders and outsiders alike would flagellate the software industry for its bug-ridden products, inability to meet deadlines, and high project failure rates. They would claim we were doing everything wrong; yet, somehow, the critics could never spell out a provably right way to do it.

This preoccupation with perfection created a subindustry of its own. Innumerable software development processes were invented and marketed. Companies practicing these processes would sell software for implementing the processes, yet their products suffered just as many bugs and release schedule delays as those of their prospective customers. Book publishers created entire series dedicated to one development methdology or another. Ironically, a number of these books were written by programmers who used the processes they described on projects that were cancelled after failing to deliver according to schedule. The search for the holy grail of software engineering never bore fruit.

The More Things Change, …
It was true in 1975 and it's true in 2005; there is no silver bullet that can subdue the sorrows of software development. Frederick Brooks explains the reason for this phenomenon in his well-regarded collection of essays in The Mythical Man Month (Addison Wesley, 1995). I would hope that most programmers who have been working for more than a few years have come to that realization on their own. Some things you only truly appreciate after learning them from the school of hard knocks.

If you believe software construction projects are more effective today than in the past, just study the FBI's recently cancelled virtual case file software project. It was started in 2002 and cancelled in 2005 after spending 170 million dollars. Or study Chrysler's famous Chrysler Comprehensive Compensation (C3) payroll software project that was cancelled after four years for not meeting its objectives, despite the acclaimed progenitors of extreme programming (XP) having formed the development team. The fact of the matter is that most software projects still fail, and even the best software team in the world can lay a rotten egg.

A secret about computer programming that many continue to deny is that it is just like everything else. I don't care if you're building a bridge, an airplane, or a house. The same factors that produce successful hardware projects produce successful software projects. The same factors that produce failed hardware projects produce failed software projects. I'm not referring to a specific process that you can follow like a recipe to guarantee success or failure. Instead, I'm referring to fundamental practices that are common to all effective development methodologies.

Outside of purely artistic or research endeavors, you can't build something if you don't know what it's supposed to do. That's why we gather requirements. You can't verify something does what it is supposed to do unless you can test it. That's why we develop test plans, and an entire taxonomy of testing has emerged to help us apply the appropriate kinds of tests to our particular software project. Again, outside of the arts and research, you can't build something if you don't know what it's going to look like. That's why we design what we're going to build before we build it, even though we may iteratively refine the design during construction.