How to Design the Bugs Out
- Bug proof the definition: The most damaging and subtle bugs arise during the designing of a system. Hence conceptual integrity of the system is of utmost importance. This can be achieved by nominating a single person or a small well-knit team that designs the system and contribute to design decisions for any changes.
- Testing the specification: Before any code is written, the code specification should be tested by a testing team. Developers won’t highlight all the gaps and obscurities, their focus is to translate specification into code.
- Top-down design: Designing should be considered as a sequence of refinement steps. The first step is to define a rough solution that achieves the desired outcome. Next, the solution should be broken down into smaller chunks and each piece should be closely examined and defined.
- Use tested components: Often we deploy partially tested components in the hope that we would find integrations defects sooner rather than later. Even more often we use the “documented bug” approach wherein we document known defects and then proceed with system testing. All this is wishful thinking, invented to rationalise away the pain of slipped schedules.
- Control change: There should be a single team/person in charge of releasing the change for testing. If a quick fix was deployed for testing to continue, it should be marked so and later re-tested thoroughly.
- Add one component at a time: Isn’t this obvious? But we are tempted to think, what if there are no bugs and everything just works.?
- Quantize update: Here there are two strategies, one is frequent but small updates, the other is infrequent but big updates. It is better to release changes in pulses, i.e. bursts of changes followed by periods of productive stability.
For me, the most interesting idea in the chapter was to test the specifications during the design phase itself. Why this has not been adopted by the IT industry? Are there any demerits? Any thoughts?
