From time to time, something happens that reminds me that our espoused theories aren’t always congruent with our theories in use (see this summary for some quick background info on those terms). The author of an article I had cited as an example of "binary thinking" posted a comment asking how I had gotten the idea that he was pro- or anti- anything. I took the question literally, and started thinking about how any of us might get the idea that another practitioner was pro- or anti- any given software development practice.
Old guys are authorized to repeat the same stories as often as they please (or as often as they forget that they’ve already told a story), so I’ll mention (again) an experience that occurred during a workshop on using causal loop diagrams for root cause analysis. The group comprised 35 advanced programmers who practiced Extreme Programming (XP), and no one representing other roles in software development. Possibly due to the programmer-centric mindset, none of the small working groups in the room was able to come up with any possible cause for technical debt than "management pressure to deliver."
This seemed odd to me, as the direct cause of technical debt is usually careless programming, and these were XP practitioners. XP doesn’t encourage careless programming. Of course, a team may trade technical debt for short-term business value, with full awareness that the cost is deferred until later, but the more typical cause is simply lack of professional self-discipline in applying well-known good development practices. So, if this group set aside XP practices whenever they felt delivery pressure, what did that say about their confidence in the development techniques XP defines? Their espoused theory was that the XP practices are the best way to deliver software, but their theory in use (as demonstrated by their behavior under pressure) was that hacking up code quickly was the best way.
What does that have to do with the question at hand? Well, it’s easy enough to compose a blog post, an email, a tweet, an article, or what-have-you that states what we want to believe is a good practice. When our project is moving along nicely and we’re skipping through a poppy field in the land of unicorns and rainbows, it’s not difficult to maintain self-discipline in using the practices we claim to trust. But when the pressure is on, when we simply don’t have the time to wait for answers to questions, to chase down and correct defects, or to absorb the cost of re-work, we do whatever we genuinely and deeply believe will get the job done, and nothing else.
So, I might venture a guess about what the author of that article supports or doesn’t support as a good development practice on the basis of his writing, but I can’t know what he supports just by reading his words. My guess might be right or wrong, but it can only be a guess. There’s only one way to know what he really considers to be good development practice, and that’s to work side by side with him on a project that’s in trouble, and see what he actually does under those less-than-ideal conditions.
Extreme Programming and the Death March
I sometimes think of XP as analogous to a Death March. The Death March is a standard phase in traditional SDLC methodologies, usually documented using invisible ink in the formal description of the methodology so that management types can pretend they didn’t know it was going to happen. You might call it "implausible deniability." In the Death March phase, team members create a "war room" (which may be an actual room or may be a section of cubicle space with the inner partitions removed), and work in close collaboration more-or-less non-stop until they complete the objectives. During the Death March, the team does whatever they believe will get the job done, and absolutely nothing else.
Everyone who has skin in the game is physically present in the war room throughout the Death March phase. There is no time for delay waiting for people to return phone calls, answer emails, or schedule formal meetings. People in all roles work in the same physical space, sometimes in pairs or small groups and sometimes individually, but always in close proximity and with frequent communication. They apply whatever practices for analysis, testing, coding, and troubleshooting they believe will get the job done without creating further problems.
If you took a Death March phase and stretched it out over time so that it wasn’t stressful, and chopped off the front 90% of the project where people waste a lot of time on non-essential activities, you would have an "agile" project using XP. It would be all about doing what really works, and not doing the other stuff.
The question is what you think "really works." When you are under Death March conditions, or when you have chosen a development methodology based on the rigorous, disciplined application of specific practices (such as XP), your theory in use is demonstrated by the way you work. Which practices do you consider "optional" for effective delivery of software? Which practices do you set aside when you’re under time pressure? Why?
What do I think "works?"
When I’m under time pressure to deliver, I prefer the following to be true:
- Everyone I might need help or answers from is accessible without delay.
- People in every relevant role are accessible for direct collaboration as needed.
- Everyone who might be needed to help with integration is accessible without delay.
- Access rights to all necessary systems, even if granted only on a temporary basis.
Practices that help me get through the situation with a minimum of delay and problems:
- Version control.
- Continuous integration.
- Test-driving code changes with incremental refactoring.
- Pairing as needed, including across disciplines.
- Easy deployment and back-out; automated, if feasible.
Your mileage may vary, as the saying goes, but in my experience self-discipline about these things gets me through the Death March and safely home faster than any other approach.
It’s interesting how similar those Death March survival factors are to normal operating procedure on an XP team. It’s almost as if the creators of XP knew something about software development. Go figure.