CodeBork | Tales from the Codeface

The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.

Project maintained by Hosted on GitHub Pages — Theme by mattgraham

Any good carpenter, joiner, or other worker of materials will tell you to “measure twice, cut once”. This is a good philosophy to apply to life and your craft as a software engineer. It implies attention to detail, efficiency and proper preparation; it results in “right first time” components and products, quality and reduced waste.

So, getting your pre-requisites right is important. There are different opportunities to emphasis quality: at the beginning of the project (planning and design), during the construction of the product and at the end of the project (testing). During the construction phase, your only option is to build the product solidly, with quality materials and tools. At the end of the project, when your only option is testing, you can’t detect that your product is the wrong solution for the problem, or that it is the right product built in the wrong way. Testing is only one part of quality assurance, and only ensure that the thing is fit for purpose.

Therefore, the planning and design stages are your one opportunity to “get it right”, and the cheapest opportunity to resolve any issues. You can, and should, make sure you have the right project and the right plans, and ensure the design is fit for the product. It’s a risk reduction process. As my Dad used to tell me, and as his boss (fittingly, in the construction industry) used to say, remember “The Seven Ps”: Proper Preparation and Planning Prevents Piss-Poor Performance. Conversely, many programmers (myself included), rarely stick around to prepare ahead, and just dive right in. Why is this? Why don’t programmers prepare ahead? McConnell proposes a number of reasons:

  1. They don't know how
  2. They can't wait to start programming
  3. Pressure from above

There are, of course, possible solutions to these, ranging from education to self-discpline to resistance (overt or covert). The key thing, though, is to learn from your rushed jump-in-the-deep-end attempts. Are the problems you experienced similar to other problems? Could they have been foreseen?

McConnell also proposes his four-point “Utterly Compelling and Foolproof Argument for Doing Prerequisites Before Construction” (UCFADPBC, for those who prefer snappy initialisms).

  1. Appeal to logic   It makes sense to plan first, and the amount of planning that is sensible is directly proportional to the size of the project. It also makes sense to design first; going down blind alleys wastes time, and time is money.
  2. Appeal to analogy   Building a house will require architectural drawings, blueprints, etc., before you can lay foundations. You don't start decorating the Christmas tree before it's in the stand. There are more :-)
  3. Appeal to data   McConnell references studies conducted by industry giants such as Hewlett-Packard, IBM, and others, that prove that it pays to do things right the first time, and that unnecessary changes are expensive. The table below illustrates the relative costs of fixing defects based on when they're introduced into the product, and when they're detected.
  4. Boss-readiness Test   It's difficult to summarise this. Essentially, "make sure your boss understands the importance of pre-requisites".
Average Cost of Fixing Defects Based on When They're Introduced and Detected
Time Detected
Time Introduced Requirements Architecture Construction System Test Post-Release
Requirements 1 3 5-10 10 10-100
Architecture — 1 10 15 25-100
Construction — — 1 10 10-25

Different projects need different approaches; for example, the space shuttle software development process is really very different from your favourite Agile methodology: the former is very sequential and very bureaucratic by necessity; the latter is fast, light-weight and very iterative. McConnell mentions that projects generally aren’t exclusively sequential or iterative, but are a mixture of the two. For example, for a systematic change, you might do 80% up-front work; for an incremental change, it might only be 20% up-front work. The choice of approach depends on the type of the project, the formality of the project, the technical environment, staff capabilities and the project’s business goals. McConnell provides the following comparison of when sequential and iterative methodologies might be appropriate:

Sequential Iterative
Stable requirements Requirements are not well-understood
Straightforward and well-understood design Design is complex, challenging, or both
Dev team is familiar with the application's area Development team is unfamiliar with the application's area
Project contains little risk Project has a lot of risk
Long-term predictability is important Long-term predictability is not important
Cost of changing requirements, design and code downstream is likely to be high Cost of changing requirements, design and code downstream is likely to be low

The next post in this series will cover specific pre-requisite activities, such as requirements and architecture.