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.
Take a minute to look around yourself and imagine how many interdependent chains of specialists and handoffs were required to produce the materials that make your life quite a bit more comfortable than our cave dwelling ancestors.
Total self sufficiency is a great concept, but if you had to do all the work to produce all of the things you take for granted, you wouldn’t be able to. You simply wouldn’t have enough time.
In software development, above a certain (unknown) level of complexity and size, specialists, dependencies, and handoffs are required to have any chance of getting the work done and the product integrated. Cross-functional teams, where every single person on the team knows how to design and code every functional area of a product, is an unrealistic pipe dream for anything but trivial products.
Documentation can be organized, structured, archived, searched. Verbal communications can’t.
Check out these two communication system configurations for developing software.
The system on the left, which depends (almost) solely on face-to-face collaboration, is the “agile” way. The system on the right, designed around a living, breathing, Repository Of Shared Understanding (ROSU) and supplemented by face-to-face conversation, is the “traditional” configuration.
As the previous paragraph implies, “agile” doesn’t recommend no documentation generation. It simply relegates the practice of document creation to the back of the bus. The idea, premised on the myth that documentation isn’t a required deliverable (in my industry it is) and the truth that programmers hate to write anything but code, is to supplement face-to-face communion with temporary, discardable, napkin scribblings and incomprehensible whiteboard snapshots.
Which system configuration do you think is more scalable? Which is more effective for long-lived, software-intensive products? Which do you think is better, more accommodating, for onboarding future team members? Which do you think is more effective for investigating/understanding/debugging system level failures (not unit level failures)?
Agilists will often bolster their “minimal documentation” approach with the assertion that requirements and design documents become obsolete as soon as the ink dries. Well yeah, if the team doesn’t continuously update its ROSU, then they’re right. But why is it such a big deal to keep the ROSU in synch with the code? The big deal is that it’s tough to sustain the discipline and resolve to so.
One of the first from-scratch products I ever worked on was named “BEXR” (Beacon Extractor & Recorder, pronounced “Beck’s-uhr“). I proposed the name BEVR (Beacon Evaluation & Video Recorder, pronounced “beaver“), but it was shot down by the marketing department immediately for who knows why :)
BEXR was a custom hardware and software combo that connected to the raw, low-level, return signals received by FAA secondary surveillance radars from aircraft-based transponders. The product allowed FAA maintenance personnel to observe and evaluate the quality of radar and transponder signals in real-time – much like a specialized oscilloscope. In addition, it supported recording and playback capabilities for off-site analysis.
Despite it’s utility to the FAA, BEXR was politically controversial. Since non-conforming aircraft transponders were relatively expensive to fix and reinstall, owners of small aircraft did not like being “spied upon“. They did not want to know if their equipment was out-of-spec. Thus, BEXR’s mission was limited to troubleshooting only radar issues.
BEXR was comprised of two, custom-designed, 16 bit, PC-AT bus cards. They were packaged in a portable PC that was carted to/from the radar site under investigation. I was the BEXR product manager and the GUI developer. I wrote the GUI Operator Control Software (OCS) in C using Microsoft’s Quick C IDE. The software directly used the Windows 3.1 C APIs to display application-specific windows, dialog boxes, target positions, and control buttons/lists. Compared to today’s GUI tools/API’s, it was the equivalent of writing assembler code for GUIs, but I had a lot of fun writing it. :)
The reason I decided to write this post is because I recently ran across a pack of sticky cards that we used to market the product and hand out at trade shows. It was a blast from the past….
Where do you fall on this Twitter Behavior Scale?
Here’s a structured decomposition of some of the program’s stakeholders.
Now, all I gotta do is find out who the “product owner” is and invite him/her to our daily Scrum standup meetings. Better yet, I’m gonna hire an “agile scaling” expert to parachute in and guide the team to on-time, under-budget success.
As you can see from the following slide, the program is docu-centric. Not one, but three upfront plans? WTF! No problemo. I’ll just sit all the stakeholders down and convince them all that “traditional” documentation stuff is unimportant and so-yesterday.
To hell with any upfront requirements and design thinking and capturing, we’ll start TDDing our way forward, discovering what needs to be done as we go. From day 1, we’ll start delivering software in monthly increments for the entire 3 year duration of the program. We’ll simply mock out all the mechanical, microwave, and digital signal processing hardware so we can go faster than a speeding bullet – twice the work in half the time. Trust us, it’ll all work out – we’re agile.
Note: You can get the full deck of slides from FedBizOps.com.
On my first pass through Bertrand Meyer’s “Agile!” book, I interpreted its contents as a well-reasoned diatribe against agilism (yes, “agile” has become so big that it warrants being called an “ism” now). Because I was eager to do so, I ignored virtually all the positive points Mr. Meyer made and fully embraced his negative points. My initial reading was a classic case of the “confirmation bias“; where one absorbs all the evidence aligning with one’s existing beliefs and jettisons any evidence to the contrary. I knew that the confirmation bias would kick in before I started reading the book – and I looked forward to scratching that ego-inflating itch.
On my second pass through the book, I purposely skimmed over the negatives and concentrated on the positives. Here is Mr. Meyer’s list of positive ideas and practices that “agile” has either contributed to, or (mostly) re-prioritized for, the software development industry:
- The central role of production code over all else
- Tests and regression test suites as first class citizens
- Short, time-boxed iterations
- Daily standup meetings
- The importance of accommodating change
- Continuous integration
- Velocity tracking & task boards
I should probably end this post here and thank the agile movement for refocusing the software development industry on what’s really important… but I won’t :)
The best and edgiest writing in the book, which crisply separates it from its toned down (but still very good) peer, Boehm and Turner’s “Balancing Agility And Discipline“, is the way Mr. Meyer gives the agilencia a dose of its own medicine. Much like some of the brightest agile luminaries (e.g. Sutherland, Cohn, Beck, Jeffries, Larman, Cockburn, Poppendieck, Derby, Denning (sic)) relish villainizing any and all traditional technical and management practices in use before the rise of agilism, Mr. Meyer convincingly points out the considerable downsides of some of agile’s most cherished ideas:
- User stories as the sole means of capturing requirements (too fine grained; miss the forest for the trees)
- Pair programming and open offices (ignores individual preferences, needs, personalities)
- Rejection of all upfront requirements and design activities (for complex systems, can lead to brittle, inextensible, dead-end products)
- Feature-based development and ignorance of (inter-feature) dependencies (see previous bullet)
- Test Driven Development (myopic, sequential test-by-test focus can lead to painting oneself into a corner).
- Coach as a separate role (A ploy to accommodate the burgeoning agile consulting industry. Need more doer roles, not talkers.)
- Embedded customer (There is no one, single, customer voice on non-trivial projects. It’s impractical and naive to think there is one.)
- Deprecation of documents (no structured repository of shared understanding to go to seek clarification on system level requirements/architecture/design issues; high maintenance costs for long-lived systems; costly on-boarding of new developers)
I’ve always maintained that there is much to like about the various agile approaches, but the way the agile big-wigs have been morphing the movement into a binary “do-this/don’t-do-that” religious dogma, and trashing anything not considered “agile“, is a huge turnoff to me. How about you?