Rational Design Process: How and Why to Fake It

Some software engineering articles don’t seem to age. For example, the 1986 article “A rational design process: How and why to fake it” [doi][pdf].

Back then, software engineering was looking for a so-called rational design process, i.e., a software development process that, if followed rigorously, would lead to the highest quality software with the lowest cost. Nowadays, that process is often called “waterfall” and is almost used synonymously with “bad software design”, having been replaced with processes like “agile”, “scrum”, “kanban” or “lean”. In essence, the waterfall model argues for a few different phases: requirements gathering, high-level system design, low-level module design, implementation and documentation. Each phase finishes with an artefact (documentation or code), that once produced is set in stone.

We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance.

The cited paper makes the case that requirements are vague and volatile, hence the final software will not have followed a rational design process, no matter how hard one tries. Instead, the paper argues to fake a rational design process, by producing said artefacts, as if a rational design process had been followed. In essence, the artefacts are updated to reflect the latest decision, for example, the requirements document is updated if during implementation a new requirement is discovered.

It is interesting to note how well the article has aged. Since its publication, Agile development methods have long argued from the engineering side to implement as little as is needed for delivering value to the customer. A bit later, the business side joined. Lean thinking has explicitly acknowledged that one discovers the market’s needs by building a product. “Build measure learn” is the new mantra. In a way, the project passes iteratively through the rational design process, but each phase is performed only for as much as is needed to learn something new from the market.

Another way to see lean thinking is to reduce Work-In-Progress (WIP). A requirement document with many unfulfilled requirements is a WIP. An architecture document with many unimplemented modules is a WIP.

However, while lean thinking puts a lot of focus on minimizing WIP, it puts less focus on faking a rational design process: Reading patched documentation or code with many TODOs raises the bar for newcomers, both customers and engineers. It is best for them to get a snapshot of documentation and code, as if everything was “done”.