Agile Architecture Myths #2 Architecture Decisions Should Be Made At the Last Responsible Moment

In Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck describe “the last responsible moment” for making decisions:

Concurrent development makes it possible to delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative.

And Jeff Atwood, in a thought-provoking blog argues that “we should resist our natural tendency to prepare too far in advance” especially in software development. Rather than carry along too many unused tools and excess baggage, Jeff admonishes,

Deciding too late is dangerous, but deciding too early in the rapidly changing world of software development is arguably even more dangerous. Let the principle of Last Responsible Moment be your guide.

And yet, something about the principle of the last responsible moment has always made me feel slightly uneasy. I’ve blogged about a related topic (just barely enough design) before. And be aware that in both my personal and professional life that I am not known as someone who plans things far out in advance. As a consequence I rarely use frequent flyer miles because I don’t anticipate vacation plans far enough in advance. I am not known to get to the airport hours ahead of my flight either. My just-in-time decision-making and actions have been known to make my travelling companions a bit uneasy. They prefer a not so tight timeline.

But what about software development? Well, if I find an approach that seems worth pursuing, I’ll typically go for it. I like to knock off decisions that have architecturally relevant impacts early so I can get on to the grunt work. A lot of code follows after certain architectural choices are made and common approaches are agreed upon. Let’s make a rational decision and then vet it, not constantly revisit it, is my ideal.

Yet I know too-early architecture decisions are particularly troublesome as they may have to be undone (or if not, result in less-than-optimal architecture).

So what is it about forcing decision-making to be just-in-time at the last responsible moment that bugs me, the notorious non-planner? Well, one thing I’ve observed on complex projects is that it takes time to disseminate decisions. And decisions that initially appear to be localized (and not to impact others who are working in other areas) can and frequently do have ripple affects outside their initially perceived sphere of influence. And, sometimes, in the thick of development, it can be hard to consciously make any decisions whatsoever. How I’ve coded up something for one story may inadvertently dictate the preferred style for implementing future stories, even though it turns out to be wrongheaded. The last responsible moment mindset can at times lull me (erroneously) into thinking that I’ll always have time to change my mind if I need to. I’m ever the optimist. Yet in order to work well with others and to produce habitable software I sometimes need a little more forethought.

And so, I think I operate more effectively if I make decisions at the “most responsible moment” instead of the “last responsible moment”.

I’m not a good enough of a designer (or maybe I am too much of an optimist) to know when the last responsible moment is. Just having a last-responsible moment mindset leaves me open to making late decisions. I’m sure this is not what Mary and Tom intended at all.

So I prefer to make decisions when they have positive impacts. Making decisions early that are going to have huge implications isn’t bad or always wasteful. Just be sure they are vetted and revisited if need be. Deferring decisions until you know more is OK, too. Just don’t dawdle or keep changing your mind. And don’t just make decisions only to eliminate alternatives, but make them to keep others from being delayed or bogged down waiting for you to get your act together. Remember you are collaborating with others. Delaying decisions may put others in a bind.

In short: make decisions when the time is right. Which can be hard to figure out sometimes. That’s what makes development challenging. Decisions shouldn’t be forced or delayed, but taken up when the time is right. And to help me find the right times, I prefer the mindset of “the most responsible moment” not the “last responsible one.”

10 thoughts on “Agile Architecture Myths #2 Architecture Decisions Should Be Made At the Last Responsible Moment

  1. Pingback: Tweets that mention Agile Architecture Myths #2 Architecture Decisions Should Be Made At the Last Responsible Moment - The Responsible Designer --

  2. While thinking of the “MRM” instead of the “LRM” may help convey an important distinction, LRM proponents would argue that it’d be irresponsible to wait after the MRM to decide, hence making the MRM == LRM.

  3. Khan- I see your point, and agree that in a perfect world what you say is true.
    But I think that (mis)perceptions about Responsible Moments can cause people to not decide at the opportune time. And sometimes what I consider the last responsible moment may feel too risky for you….in that case what should we do? Especially if there is a team involved.

  4. Pingback: Architecture at Agile 2013 : Mozaic Works

  5. “Making decisions early that are going to have huge implications isn’t bad or always wasteful”. Except that LRM philosophy would argue that if not making them would have “huge” or irreversible implications, then the decision should be made. At that time, cost or potential cost of not making the decision does indeed outweigh the cost of making it.

    The fact that a decision has huge implications doesn’t mean that it has huge implications right now. That the implications are huge suggests that the consequences of discovering new information after the decision has been made is even greater – posing a stronger argument for putting it off as long as possible.

    Certainly, one could fine a singe decision or sub set of decisions with a project that carry with it no penalty if made early — but given the inability to predict the future, this assessment can only truly be made after the fact. In aggregate, as long as decisions are not made after the optimal time, the most efficient and least risky option is to defer decisions as long as possible.

    The argument of not knowing the optimal decision time is the better one. However, if you are prone to forgetting to make the decision or making it late – that is an input that goes on the consequence side of the equation. The LRM for you is earlier because the impact of not making is to forget. It is still the last responsible moment for your particular case based on your particular input. If, however, you had a calendar event set to remind you of the coming decision – then it would be arguably wasteful to make it now based solely on the potential of forgetting it.

    Any argument against LRM is generally one that lists reasons in an assumption that they are not considered in the LRM equation. However, add those reasons back into the equation and you once again have a very healthy philosophy.

  6. Steve-
    Thanks for your thoughtful comment. One point I wanted to make in my post is that some decision makers behave differently when they operate in a last responsible moment mode… they don’t add in the comfort level of others involved and/or the time it takes to move big ships around or the time it takes to actually respond to decisions (they are, perhaps, overly optimistic). I’ve seen this really torpedo large projects or programs. What I think the LRM philosophy is trying to avoid is stale decisions that are immutable.

    I share that view.

    I still question whether it is always prudent to defer decisions as long as possible. And we can argue endlessly about when the last responsible moment is different than the most responsible moment (and why these terms make some unconfortable). I just want to get people thinking….. Decision-making impacts a team, and the larger the team, the more impact “too late” or “premature but wrong headed that could have been avoided if we’d waited for more information” decisions have.

    And no one wants that

  7. The title of the article is worded much stronger than “wanting to get people thinking”. We can agree I think that the use of the word Myth is much more contrarian than that.

    In chapter 3 of McConnell’s iconic book “Software Project Survival Guide”, he introduces the idea of phase containment, that defects should be corrected in the same phase in which they are created. He justifies this statement by demonstrating that defects cost 50-200 times as much to correct later in the project than in the phase it was created. The relationship is non-linear, the earlier the defect, the greater the cost to fix later.

    Every decision is in fact a potential defect – something that may need corrected later on. Given the non linear nature of the cost to correct as time passes, it becomes easy to argue that to error on the side of too late vs. too soon is more forgiving — unless you can show that the consequences of too late are either terrific or non-linear as well. Those decisions are usually easier to identify though. It is fairly obvious, for example, that your project needs funded and that failing to do so would bring a halt to development.

    I believe the mistake that you are more likely responding to with LRM is to believe it to suggest that decisions can simple be ignored for the sake of laziness. Such is not the case. Forgoing a decision should be a decided and intentional act – understood and agreed upon by the team and regularly considered as the project progresses. Put a different way, LRM philosophy would not allow you to have any fewer requirements , do any less up-front work, be any less communicative with the team, or even let you sweep decisions under the proverbial rug. What it does let you do, however, is say that “We think AWS will have feature X in the next three months that will make deployment much easier than it is today, but we can go ahead now and start writing code with the knowledge that we have to figure out deployment later.”

    That people are interpreting and implementing LRM incorrectly I would agree with; That is different than saying it is a myth. To title an article such that it suggests a failed philosophy demands a far stronger argument – one I don’t believe is provided.

  8. I don’t think people are lazy so much as they don’t appreciate the impact of the cost of delaying a decision (that could be decided earlier) has on other people. One definition of myth is that it is an “an unproved or false collective belief that is used to justify a social institution”…and so, I think that saying LRM is a good way to weigh and judge all times for decisions is just that: an unprovable belief. It is impossible to know post- apriori decision making time what the consequences would have been siding the decision forward or backwards in time. We can only guess about impacts. Yet still, I appreciate that LRM has gotten people to defer decisions appropriately. But when it is touted as the “best” way to make decisions and people are not willing to really scrutinize things, then I get a bit concerned.

    A side note about your AWS example. Given that I expected that AWS would have a new feature in 3 months wouldn’t necessarily cause me to make a decision to continue on as is (hoping that we’d figure it out later). As someone who favors the “most responsible” moment to decide, I’d have to weigh risks vs. benefits. And consider my options.

    Again, thanks for your comments.

  9. I apply a structured yet very simple and straighforward approach to LRM, which I believe makes it equal to MRM;

    1. Do we have a solid, final and waterproof decision basis? (nothing to be gained from deferring; decide now!)
    2. Do we have to decide this now? (we have no choice, do it!)
    3. If we decide now (and the answer to 1. is “no”)
    3. a) What are the implied assumptions?
    3. b) What is the risk that any of these assumptions will turn out to be false?
    3. c) What will the consequences of any such failed assumptions be?
    4. If we defer the decision;
    4. a) What are the immediate and/or inevitable consequences?
    4. b) What are the potential consequences?

    Given the answers to these questions, apply your best judgement and decide whether to decide. And, always include the reasoning in your decision log; more often than you might think, it’s important to be able to understand “how did we get here.”

  10. Since this page was just linked to…

    If there is some influence that triggers a person to be “late” in their decision they have not taken responsibility for accounting for that type of influence/impact. That simple…. When the decision point is moved up to the point where that influence no longer would have impact, they are at the LRM…

    The key thing, it that the influence may change over time…and therefore the calculation and understanding of LRM must adapt…

    LRM is a significant part of our team retrospectives, usually with a focus every 3-5 sprints for significant inspection and adaptation.

Leave a Reply

Your email address will not be published. Required fields are marked *