Gustavo Duarte, software architect, created a stir when he discussed physicist Richard Feynman's findings on the Challenger Space Shuttle disaster and how they relate to engineering quality software. Gustavo's application of Feynman's principals to software yields four main points:
- Engineering can only be as good as its relationship with management
- Big design up front is foolish
- Software has much in common with other engineering disciplines
- Reliable systems are built by rigorously tested, incremental bottom-up engineering with an 'attitude of highest quality'
In a follow up article Gustavo elaborates on the concept of empirical evidence, introducing the idea of "Reality Driven Development":
Action and experimentation are the cornerstones of empiricism. No attempt is made to subdue reality by extensive analysis and copious documentation. Reality is invited in via experiments. Instead of agonizing over market research, an empirical company hires interns and develops a product in one summer. A non-empirical company has 43 people planning an off-button design for one year.
The concept, drawing from evolution, espouses the philosophy of survival of the fittest. In essence, you try some stuff, keep what works and throw out what doesn't. Gustavo explains:
A good software development process should optimize experimentation and improve feedback from reality. This is what I mean by reality-driven development. And in software the most important realities are user experience and technical quality, while the primary experiments are working software and code. This isn't a formal model (heh), it's simply my favorite analogy for software development. I like the name "reality-driven" because when you mention reality, people think of users.
The idea shares some of the core principals and techniques of Agile, however Gustavo is (thankfully) not advocating a new methodology:
There is no specific reality-driven methodology. The Agile principles have a lot in common with these ideas (and certainly influenced them), but the devil is in the details. I prefer to think of software engineering in terms of a toolbox, full of techniques we pick and choose for the right situation. Process tools for optimizing experimentation include iterative development, executable architecture, continuous integration, and unit testing.
The bias of Gustavo's approach is toward the user and quality:
Based on this model, the two realities we care about are user experience (including the software's utility) and technical quality. User experience is often neglected in agile and waterfall alike.
Gustavo concludes with a refinement of his bottom-up approach:
- Have a bias for experiment over analysis, though both have their place.
- Optimize experiments: make them as early, fast, cheap, and broad as you can. Analysis can help here.
- Experiment vigorously.
- Be smart and proactive about measuring reality: user experience and technical quality.
- React to feedback. Let reality drive.