The R.A.C.H.E method: Rapid Application Conception and Heuristic Extreme-programming
There is a software engineering method that describes real life better than half the frameworks I see pushed through a review board. That method has an acronym, an institute, a FAQ and a public-domain licence: it is called the R.A.C.H.E method. I discover it around 2009-2010, at a time when I still take roadmaps seriously.
R.A.C.H.E stands for Rapid Application Conception and Heuristic Extreme-programming. The site of the International Institute of La RACHE has existed since 2007, but the concept already circulated as a PDF before that. The recurrent metempsychosis of the concept is, according to its own promoters, intrinsically axiomatic at some large vendors. la-rache.com
The I.I.LaR
The International Institute of La RACHE, or I.I.LaR, exists to promote the method, whose definition is remarkably precise:
La RACHE, a global software engineering solution, is a set of techniques, methods and good practices describing - from specifications to maintenance - how to produce software in conditions that are pretty much satisfactory and approximately optimal.
That level of rigour is exactly the one of most project plans I get to read. The corpus is apparently certified compliant with ISO-1664.
Rapid Application Conception
Scoping is a post-it of at most eight words: summarise the need inside it. The project duration is then obtained by multiplying the number of words by a coefficient between twenty and two hundred man-days. Nothing more is planned (the post-it loses its grip over the weeks, which is a physical reminder of the real state of the project).
Heuristic extreme programming
Heuristic, the method reminds us, is the art of having others do what you do not know how to do yourself; applied to software engineering it yields heuristic extreme programming, where you start writing code as late as possible, because everything written too early is to be rewritten. I know no agile method that puts it better in so few words.
The lexicon
The lexicon is the showpiece. It offers the R.A.T.P, Régulateur Asynchrone Temporel Pifométrique, an asynchronous temporal pifometric regulator that beats classical man-days estimation hands down, as well as the U.R.M.L, Unified Random Modeling Language, a stochastic variant of UML whose diagrams change on every reading. The R.A.T.P has the merit of being honest: it announces that it does not know, where the classical plan pretends it does.
[edit: 2014] The lexicon has since gained a D.O.C.K.E.R entry, Deployment Of Containers with Known Errors and Restarts, stacking containers without much knowing what is in them and restarting when they fall over.
The FAQ
The FAQ brings the clarifications that roadmaps forget: a system developed La RACHE style is in a working state when it has not crashed yet. It is then urgent not to touch it any more. As for the question of who is responsible in case of an incident, the answer is: nobody, the method produces software in conditions that are pretty much satisfactory, not culprits.
That is the passage I quote most in an architecture review.
Why the satire rings true
A joke that has held for a few years always ends up telling the truth. Every La RACHE principle is the clean negative of a good practice: configuration kept out of the code answers the famous “it works on my machine”, disposability answers the system nobody dares to restart any more. The failure you rehearse on purpose answers the incident you discover in the middle of the night, when nobody is around to watch it come.
The difference is the contract: La RACHE announces from the start that everything is going to go approximately well, where the good practices write down in black and white what they guarantee and what they do not.
I re-read the site once a year. It still holds.