Good Software Takes Time

There was a uniquely insightful editorial in the Washington Post this morning about some of the pitfalls and delays that plagued Microsoft’s Windows Vista project.  One of the most insightful quotes was near the end where it talks about how software engineering “has proved uniquely resistant to engineering discipline.”  Another good article on this subject was written a number of years ago by Joel Spolsky, a software engineer in New York, entitled “Good Software Takes Ten Years.”  Spolsky talks about a number of mistakes that are made in software development and demonstrates a relatively steady relationship between the time a project is started and when it reaches maturity.  While these articles bring up many good points, I also believe that some of the engineering discipline that is being brought to the field has drastically shortened this ten year curve as well.

As a software engineer, I have seen many of the pitfalls of large software development project first hand.  It is almost always a combination of items that cause a software project to fall behind or end up over budget.  Scope creep, poor requirements, and changing software and hardware are just a few of the many problems that affect good software development.  Customers often see what you are accomplishing at the beginning of the project, become enamored, and want more.  This results in an inevitable delay as new features are architected in and developed if you don’t closely control the creep during the project.  At Rocky Flats, this was a constant problem with almost every project I worked on, and tends to be exacerbated when your customers are not particularly computer literate. 

In this particular case, Microsoft also suffered from over promising at the outset.  This is another common problem in software development.  Everyone wants to say, “Yes, we can do that,” sometimes without knowing all of the possible pitfalls along the way.  When I was at Rocky Flats, Mike Nigbor showed me a triangle that he had picked up from a colleague representing the facets of software development.  One side represented the amount of features, one side represented high quality, and the other represented time.  He said, you can pick any two sides.  You can have a lot of features quickly, but quality will suffer.  You can have a lot of features and high quality, but it will take a long time.  You can have it quickly and high quality, but the number of features will go down. 

Delivering good software on time and on budget is an exercise in managing customer expectations for what can be accomplished in a given amount of time.  It is up to the software architects and their developers to set reasonable expectations given their knowledge and expertise.  While some progress has been made, large software projects, like Windows Vista, will continue to be plagued by delays and overruns simply because the pool of unknowns at the beginning of the project is larger on projects of that scale.  As an industry, I believe we are beginning to learn more about how to apply engineering discipline to the creation of software.  Every year, there are new tools and methodologies to help contain some of the risk in large software development project.  Frameworks such as Microsoft’s .NET and tools such as the Visual Studio Team System are just beginning to help impose more discipline in the software world.  However, even with the engineering methodologies that are available, software largely ends up being an exercise in finding out what is possible and creating something new where nothing existed before.  If we were simply creating systems that did the same thing that we had done a hundred times before, then we would be on time and on budget every time.