Real-World Maintainable Software

Chapter 1. “How Did We Get into This Mess?”

Cape Canaveral, Florida. November 8, 1968. At precisely 9:46 a.m., the Delta E rocket ignites, propelling the Pioneer 9 spacecraft into the atmosphere. This is the fourth in a series of space missions directed at studying “space weather.”

The program was highly successful: while designed to last for six months, it provided data for 35 years. The main contractor of the Pioneer 6-9 program was TRW, a company in charge not just of the construction of the spacecraft but also of the design and implementation of the software that governed it. This was during the relatively early days of the software development industry, and there weren’t too many references on running software development projects. Perhaps for this reason, Winston W. Royce, one of TRW’s most prominent software development project managers, published in 1970 a paper titled “Managing the Development of Large Software Systems,” in which he described his views on making software projects succeed. Royce’s paper was famously attributed as being the first written reference to the Waterfall Development Model, describing it as a “grandiose approach to software development.”

This model took the world by storm. Companies all over the planet started to follow this methodology. Certifications were created for project managers who would be accredited as following the Waterfall Model to the letter. Teachers of computer science in universities of all countries included them in their lectures. For many decades, the Waterfall Model was adopted without question as the best and only possible way to develop software.

Figure 1-1. The Waterfall Development Model as described in Winston W. Royce’s paper

However, in what may be a prophecy of the hunger for quick wins that would come to plague the software development industry, the early adopters of the Waterfall Model failed to properly read Royce’s paper. Even though he described the Waterfall Model as the ideal way to build software, he also said that “the implementation described above is risky and invites failure.” He then went on for several pages explaining the risks and downsides of his model, concluding that the only way to make it work is to run the same project at least twice so that subsequent implementations can learn from the mistakes of the previous ones.

And so it happened that software projects across the board consistently failed to meet expectations for decades. In 1994, the Standish Group published their first CHAOS report, a survey covering more than 8,000 applications, in which the overall success of software development projects throughout the industry was assessed. The results were abysmal: 31% of projects were cancelled before completion, 53% were finished with reduced functionality and/or over budget, and only 16% finished successfully according to the initial parameters.

Maybe because of these results, project managers began to worry about hitting deadlines above anything else, and potentially at the expense of long-term instability. This had the effect of increasing the costs of maintaining the code after delivery, with some sources like the IEEE estimating that maintenance causes around 60% of the total cost of the project.¹

Step by step, failure after failure, the software development industry realized that something needed to be done differently. In 2001, the Agile Manifesto was signed, encouraging a new way of thinking about software development. Companies that began to deviate from the norm experienced the benefits. In the latest CHAOS report, results were segregated for Agile and Waterfall projects: while 29% of Waterfall-led projects are still cancelled (signifying virtually no improvement after 11 years), the failure rate of Agile-led projects is down to 9%.

It’s taken time, but companies finally realize that, for a project to succeed, focus needs to be placed on the long term. Maintainability is the main issue, and for this to come at a reasonable cost it needs to be looked after from day one. It is for this reason that companies like SIG began to think about patterns and guidelines that can be applied to the everyday work of a software developer and that will assist in ensuring and assessing software maintainability. After years of experience, SIG has found a set of 10 easy-to-follow guidelines that will help keep code manageable for years to come, putting teams one step closer to success. This report will explore those guidelines, explain their applicability, and present them together with a set of real use cases that benefited from it.

You can start building maintainable code today by using these 10 guidelines.

¹ Robert L. Glass, “Frequently Forgotten Fundamental Facts about Software Engineering” in IEEE Software, 2001.