The Agile Architect

Want to Make the Right Decision? Procrastinate Until 'The Last Responsible Moment'

Our Agile Architect offers some last-minute, just-made-the-deadline observations on the positive power of procrastination.

I should have been writing this column, but instead, I’ve been playing cards with my sister. She trounced me. Twice. I’m in California visiting my parents for a week, so it’s been tough for me to sit down and write my monthly column, the topic of which is (yes, ironically) The Last Responsible Moment.

I’ve been talking about this concept with my parents and sister for the last couple of days. I find the idea that there can be real power in "putting it off" fascinating and completely logical, even though for years I've believed just the opposite.

I was taught that, when faced with a difficult decision, large effort, or high risk, it should be tackled early, head-on, that higher risks should be addressed as soon as possible with great effort expended to mitigate those risks. This might manifest as solving a particularly thorny technical problem, even though the use of it may be months away. Or it could be planning out a sophisticated new feature well before building it to make sure you have plenty of time to get it right.

The Last Responsible Moment

The principle of The Last Responsible Moment throws that idea out the window. It goes like this: When you are faced with a difficult decision, large effort, or high risk, you should wait as long as possible to make that decision. In fact, you should wait until the moment when not making a decision will be detrimental. I first briefly touched on this in my column, Yes, with Agile There Is Time to Think!

Among other virtues, waiting (some might say procrastinating) gives you more time to learn more about the problem you are trying to solve. Sometimes, it gives you time to learn that you don’t actually have a problem to solve. The hard part, for those of us who like solving hard problems, is to not take the problem head on, but instead to ask when the right time is to solve the problem, and then procrastinate like a high school senior studying for finals.

While talking with my family about the column that I was not yet writing, I explained this concept. My sister, who is a former ballerina with the Royal Ballet of Flanders, immediately likened it to the way a choreographer might work when commissioned to develop a ballet. They may put some initial ideas together and then wait until they meet the ballet company to become familiar with the dancers. In that way, they can choreograph to each dancer’s strengths. By waiting, the choreographer is able to create a better result than if they created everything as early as possible to “mitigate the risk” of not finishing on time.

My father, a retired college professor, chimed in that he also followed the principle of The Last Responsible Moment. He recently finished writing his memoirs, and he explained that his creative process involved first spending a significant amount of time writing an outline. As he wrote the outline, adding new events triggered his memory of other events. By working with the outline first—effectively putting off the writing, he said—he was able to plan out the entire book. Once the outline was complete, writing it was relatively easy.

This, of course, is the exact opposite of The Last Responsible Moment. He had followed what I would call The Big Planning Up Front approach. Knowing him as I do, and understanding his goals with this memoir and the demands of writing a complete book, I can say with confidence that this was probably the right approach for him. But we talked about how that might change if, for example, he was to publish that memoir in serial form with the chapters released individually over a period of time. In that case, waiting to plan out subsequent chapters until he got feedback on the first releases could help make his memoirs more compelling to his readers. Procrastination would buy him the time needed to learn what his readers were really interested in.

When is The Last Responsible Moment?

An important companion to The Last Responsible Moment is the principle of Simplicity from the Agile Manifesto. To quote the Manifesto, “Simplicity—the art of maximizing the amount of work not done—is essential.”

To me, these two principles go hand in hand. One strategy to maximally leverage the benefits of The Last Responsible Moment is to find strategies to push that moment further into the future. By following the principle of Simplicity, you may find that that moment never comes.

As an example, World Wide Technology builds a system for the Department of Defense called the Mobile Field Kit. It is used to detect evidence of the construction of weapons of mass destruction by integrating readings from multiple types of sensors, including radiation and chemical detectors. When we were deciding on the design for a canonical data representation for these detectors, we knew that the data from each detector was very different, some giving simple numeric values while others could provide multichannel spectral data. For our purposes and following the principle of Simplicity, we decided we would represent all detector data as key-value pairs, where the keys were specific to the detector type. Following the principle of The Last Responsible Moment, we figured that when we needed something more sophisticated, we’d update our representation. It wasn’t yet that moment.

Fast forward 15 years and we are still using simple key-value pairs to represent data across dozens of disparate detectors. In fact, it’s been a significant advantage in allowing us to integrate new types of detectors in days or weeks, rather than months. By delaying our decision to create a more complicated data representation, we’ve likely saved millions of dollars in unneeded development effort.

Examples of The Last Responsible Moment

Planning new product features that never get built
Planning for a new feature can be great fun as you envision new capabilities for your product, all the while imagining the delight your users will experience. But don’t start too early lest you plan out a feature that is never built, overcome by events. Perhaps feedback from your last release changes your priorities to a previously overlooked user need. Or technologies changed and the feature, as you envisioned it, now looks stale and outdated. Or budgets shrink and your team is now in maintenance mode. 

In planning a new feature, The Last Responsible Moment is the moment where not planning would delay the release of that feature. Note that to start building, you don’t have to have the entire feature planned. Only enough to get started. In fact, you’d be better off waiting to see the results of the initial development before planning the rest of the feature completely. You may learn something in the meantime.

Creating a detailed architecture that is never realized
Building an up-front, detailed architecture and/or design for a new product can be satisfying and provide the illusion of mitigating risk of the unknown. However, it is more likely that you are doing a lot of work that will rapidly become outdated as the product is built and more is learned about requirements and the always-expanding capabilities of the technologies being used. Even worse, you are likely to spend a lot of time keeping that detailed architecture up to date.

The Last Responsible Moment says to follow an emergent architecture approach, defining only enough for the work at hand. Don’t try to solve future problems. The time you save now in not doing that work will be used much more effectively later when the forces on the architecture from real working software are better understood.

Final Thoughts

Waiting to write this column until The Last Responsible Moment, the moment when my editor would become irate with me for blowing my deadline, has created a richer article, with stories more diverse than I could have related had I written this even a week early. And there is your ultimate proof that procrastination works.

About the Author

Dr. Mark Balbes is Chief Technology Officer at Docuverus. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.