Note: This is a column I added after the original four part series was published on Byte.com. The original four still comprise parts one through four in this series.
Building powerful software is hard. It is a complex, demanding process which requires organization, teamwork and communications. The skills and resources involved are not trivial. If you understand the difficult challenge of the task, you will be less surprised that one third of all major projects fail. They are usually stopped after big financial overruns, sometimes years after the original optimistic completion dates have been missed.
Many of the early projects I have been involved in had problems at delivery. Over the last twenty years of my career, I have developed a set of techniques to address those problems, keying on the hidden variable that is the primary cause of failures - Communications.
Building software is analogous to building a house: It starts with determining what the customer can afford (budget), wants (requirements) and proceeds to details (specification) and then to construction (design & implementation). After the building is done, it is inspected (quality assurance) and any problems (bugs) are fixed. Finally it is delivered - late and over budget happen here too, for much the same reasons as software projects.
The problem you face in writing specifications is that it doesn't seem to have an obvious payoff. It is easy to write up something that covers the ground but misses important points. The information below examines the eight points of specification and gives background for how and why they should be entered.
You've no doubt seen the phrase "Quality cannot be tested in". Bugs can be eradicated, but the essence of quality is knowing what you are doing every step of the way, and communicating information in a clear and unambiguous way.
Linux gets all the press, Microsoft gets all the hate mail, OS/2 gets ignored. But somehow, OS/2 users keep on running this relatively unknown and little respected system. Why? "Success has many fathers, but failure is an orphan." The failure of OS/2 to capture large market share has many causes, but here are the main ones:
With all the worry about year 2000 bugs, viruses and e-mail Trojan horses, many small and medium size businesses are working hard to prevent these problems. This is a prudent business step, but systems will fail and people will delete the wrong files despite these precautions. In addition to prevention, let's look at a complementary approach -- make it easy to recover from problems that damage vital files. While this approach is not a panacea, it does provide file recovery in whatever depth you decide to implement.
While the false millennium is less than 50 days away, the era I refer to is the one where Intel has controlled the desktop with a single architecture. From the 8080 to the 8086 to the 386 and beyond, Intel has dominated market and mindshare. What are the tools that Intel used to build this position, and how will they fare after 2000?