The RGR Prayer
I recently watched an agile training video in which the sage on the stage made the audience repeat after him three times, the RGR prayer: “red, green, refactor“.
As I watched, I wondered how many of the repeaters were thinking “uh, this may be bullshit” while they uttered those three golden words from the sacred book of agile. It reminded me of those religious ceremonies my parents forced me to attend where the impeccably dressed, pew-dwelling flock, mindlessly stood up and parroted whatever the high priest dictated to them.
Let’s digress, but please bear with me for a moment and we’ll meet up with the RGR prayer again in short order.
I know it’s not much to go by, but assume that you’re given the following task:
“Given this input, design and build a box that produces this output.”
Rising to the challenge, you concoct the following three design candidates upfront (OMG!) so you can trade them off against each other.
Which design candidate is “better“? The monolith (A), the multi-element network structure (B), or the two element pipeline (B)?
As always, it “depends“. If the functionality required to transform “this input” into “that output” is tiny (e.g. a trivial “Hello World” program) then the monolith is “best” in terms of understandability and latency (time delay from input to output). If the required functionality is large and non-linearly complex, then the multi-component network design is most likely the “best“. Somewhere in between lies the two element pipeline as the “best” design.
Hard core agilista consultants like our RGR priest and those dead set against the “smell” of any formal upfront requirements analysis or design activities would always argue: “all that time you spent upfront drawing pretty pictures and concocting design candidates was wasted labor. If you simply used that precious time to apply the RGR prayer through TDD (Test Driven Development), the best design, which you can’t ever know a-priori, would have emerged – IT ALWAYS DOES.”
See, I followed through on my commitment to weave our way back to the RGR prayer.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Looks like the video link is busted.
But even without watching. We’re entering a era where engineering, architecture, design, assessment, analysis of alternatives, probabilistic risk analysis, measures of effectiveness, measures of performance, technical performance measures, and key performance parameters are not only unheard of, they are seen as heresy. It’s an era of coders, free thinkers, anti-process zealots, and pretty much “all about me.” Pray to what ever God you pray to, these folks don’t start working on mission critical, software intensive systems that will jeopardize life, limb, and pocket book. Please dear lord let they stick of iOS games and silly useless web apps and leave flight avionics, telecom infrastructure, positive train control, emergency shutdown, distributed process control, nuclear safety and safeguards, ERP, enterprise financial, health insurance claims processing, over the horizon radar, and other systems i’ve worked on to those who understand this nonsense agile development in the absence of good engineering practices.
I couldn’t have said it better. As you have eloquently pointed out, there are domains where TDD and the other “all about me” agile practices work well and there are domains where it can be downright irresponsible to apply them. I have nothing against the agile movement except for one thing: the arrogant luminaries who imply either explicitly, or, more commonly, implicitly, that agile applies everywhere.
I heard Kent Beck say during (an otherwise terrific) talk that someone told him “Kent, you’re destroying software engineering”. Kent said he replied back with “Really? Have I REALLY destroyed software engineering?”. I personally don’t think he has, but his work has moved it to the back burner.
I think I fixed the link. Try it again. Since it links to a video in my paid safaribooksonline account, I don’t know how much you’ll be able to watch. Let me know if it works.
Thanks
Link still not there, likley because it’s paid access. No problem. Just attended an Agile and EV confernce at DOD, with prime contractors and government speaker ands DCMA in attendance. Dramatic difference from the individual agile folks I meet with once a month for coffee in Boulder. The DOD paradigm is mission first. The individual paradigm is “me first.”
One of the speaker was a vendor of agile training. My sponsor (client) “owns” earned value in the DOD, leaned over an said “nice me presentation” – all about me and my great vision on how the DOD needs to adopt agile. DOD is working very hard, SEI, MITRE, and RAND studies, along with our study efforts, but Mission First.
Agile big in the INTEL business, cyber, and rapid response systems. Most based on DODAF in some way for interoperability.
Interesting. I copied the link from the “share” button. One would think that the site would want to promote its training content by allowing some limited visibility to non-members. I must have did something wrong.
I like the way you present radical agilism as the “me” process. I think it’s fitting. From what I know about the heavy DODAF, MODAF, Zachman frameworks, I’d love to see the details for integrating agile into them. I have read a little about reconciling agile practices with CMMI KPAs.