The recent slowdown of the dot-com area has given many people plenty of time to reconsider software practices and principles. What went wrong? What could we have done differently? How did so many smart people fall into something that wasn't going to work?
Software failures are not new. In the mid-1990s, the Standish Group released its now-famous report about the alarming frequency of failed software projects. According to the report, only 16% of software projects finished on budget with all functions working. People cancelled 31% of projects in progress. Most projects (52%) finished but were late and over budget. What would the numbers be if someone were to gather data on Internet software projects?
Answers to software failures are not new either. In software, we must understand requirements, design solutions, implement them, integrate and test, deploy systems, and maintain them. There are many ways to combine these steps, but these steps are necessary.
Another age-old answer is that people produce software for people. If we don't talk with people, hold meetings with people, work through disagreements with people, and tolerate and compensate for mistakes made by people, we don't produce software. Broadband, video conference, e-mail, and other new tools and technologies can help, but they don't replace people and relationships among people.
Bruce Blum (*Software Engineering, A Holistic Approach*, http://www.amazon.com/exec/obidos/ASIN/019507159X/cutterinformatco ) called these principles the essential software process. He stated that process in three steps:
1. Translate a need in an application domain to a conceptual model.
2. Translate a conceptual model to a formal model (what the software is to do).
3. Translate the formal model into a software product. This covers all the waterfalls, spirals, and agile processes.
It seems that these old answers aren't good enough for us. We want to make up new answers. We like to stretch the rules of software development as much as we can. The problem is that when we stretch them past the breaking point, nothing immediately snaps back and stings our finger like a rubber band does when we stretch and break it. We proceed on our merry way using a broken system that we think is still working. We don't realize our folly until we have to lay people off (and get laid off too).
I am angry about this latest round of software failures. We know better. We have the answers, and they are the same answers we heard after failures in developing software for client-server, PC standalone, supercomputer, mainframe, batch processing, and other areas.
I am most angry because every software failure leaves a group of hurt people: programmers laid off, paychecks missed, stress introduced into homes, families damaged and broken.
I offer my condolences to those who are suffering from the dot-bombs. My advice is to pause and reconsider the tried and proven principles of developing and maintaining software. People have succeeded in this field time and time again, and the basic principles can help us succeed the next time.
-- Dwayne Phillips
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He wrote *The Software Project Manager's Handbook, Principles that Work at Work*, published by the IEEE Computer Society (http://www.amazon.com/exec/obidos/ASIN/0818683007/cutterinformatco ). He can be reached at d.phillips@computer.org.