Reliable Software

We've known for decades how to prevent software bugs...

1. Design from the top down and build from the bottom up.
   Only reuse modules that are completely debugged and reliable. Code built on unreliable code will be unreliable no mater how perfect it is.
   (Here I use "module" generically to mean any identifiable block of code... variously called "subroutine", "method", "procedure", "function", "macro", etc.)
   
   
2. Don't allow any module to have side effects.
   Side effects cannot be documented sufficiently to make them fully known for future work. They are thus inherently unreliable.
   
   
3. Software development is non-linear. Plan For It!
   An "80/20" rule is far closer to reality than the linear projections forced upon most software projects. To produce reasonably reliable software (we're not even going for "bug-free" nirvana here), about 80% of the development time will be spent on the 20% of the code at the bottom -- the lowest level -- the first modules upon which everything else is built.
   
   
4. Large groups cannot produce good software.
   Practically perfect software can only be produced by a team of... one. No one can wait long enough for one person to build the huge systems used today though so we have to sacrifice some perfection for the timeliness that teams can achieve. Teams of up to around 10, where each member excels in a different discipline and is responsible for a well-defined component of the project (i.e. GUI, business logic, database, testing, cat herding, etc.) can work well. Cat herders (leaders) unthreatened by more technically skilled team members can be hard to find though. We need to cultivate more of them.
   

Software development as it exists today, with its total obsession with speed of development, is untenable.

In business, software is the embodiment of a company's competitive strengths. How can a company that does everything just like their competitors hope to best them?

Government and non-profits are highly dynamic and diverse in their missions. Every software project is thus unique. How can they afford to pay the premium of profits on inferior products with their comparatively modest budgets?

Commercial software products today are much like America's luxurious but highly unreliable cars of the mid-twentieth century.... no longer affordable.

Open source projects and in-house development build on a much greater depth of knowledge of the processes being automated and thus produce more reliable and more productive systems.

Can we afford not to change?