The Last Responsible Moment

In Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck describe a counter-intuitive technique for making better decisions:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/10/the-last-responsible-moment.html

This is madness. Today’s minds have been overly affected by short attention span music videos, video games, film edits that skip around every .4 seconds, etc.

People are no longer able to focus and hold a thought, hence their “requirements” never settle down, hence “agile development”, extreme coding, etc.

I wonder what methodology the space shuttle folks use.

You shouldn’t humor this stuff, it’s a serious disease.

Steve, good comment. I never even had a project where the project specs were clear beforehand. at mostly have to actually make specs based on vague premonitions, impressions, meetings, etcetera,… making specs is putting chaotic ideaes into a somewhat structured form so you can present them back and get an “aha-erlebnis” : “now that’s what i wanted”, or not. and then you can start over. and over until they finally agree. I usually end up deciding myself what they want.
Andy

Steve, I hope you’re trolling.

I love TDD, not because I can’t focus, but because I recognize the limits of my planning abilities and those of my clients, so I’m very interested in being able to change my software while retaining confidence in its correctness.

I really feel like most opponents of agile and XP are tilting at strawmen, or at very least considering the views of some impractical XP extremists as the accepted definitions.

In general I’d agree that for some things, making the decision at the right time is key. However, that right time might not necessarily be “as late as possible”.

A few years ago I met a guy who used to be president of one of the largest insurance company in my country (it had just been sold to a german company), and he said something that seemed to make a lot of sense for a lot scenarios: “It’s better to make a decision early. That way, if you’re wrong, you still have time to turn around and change your mind. If you leave it to the last possible moment, and you choose wrong, you’re screwed”.

Steve you can continue to rail against the perceived evils of the day and continue to long for the mythical lore of yesteryear, or you you can take the red pill and realize that no matter what you wish to be true, the reality is that people have trouble visualizing a system until it’s complete.

Sure, you’d like to convince all your clients to sit down and really think about it, but you might as well try and convince everyone to stop fighting wars.

A better choice is perhaps to adapt to the reality. People have trouble making decisions on software systems early on. A software system today has more moving parts than any architectural structure build by humanity pre-computers.

Sure this doesn’t work for the Space Shuttle, but we’re not all writing space shuttle code.

Procrastination always pays off now… :slight_smile:

I agree with the principle of Last Responsible Moment, but it’s sure hard to get consensus on when that is.

In my last job, I’d try to get upper management to commit to a simple design decision and they’d often give me a lecture on how making a decision too early can paint you into a corner. So we wrote a lot of needless (and complex) if-else code knowing half of it would never be used, but that way we could deliver things that would run even if underlying decisions weren’t made until the 11th hour or were reversed after going live.

Bob Dole was apparently famous for not making decisions until necessary – those guys quoted him fairly often on this kind of stuff.

that right time might not necessarily be “as late as possible”.

As late as responsibly possible. As Doug points out, nobody can really tell you when that is. There are a bunch of guidelines in the Poppendieck book. A large excerpt from that section of the book is available here:

Morphing the Mold | Dr Dobb's

In his essay “Delaying Commitment” (IEEE Software, May/June 1988), leading British computer scientist and professor Harold Thimbleby observes that the difference between amateurs and experts is that experts know how to delay commitments and conceal their errors for as long as possible, repairing flaws before they cause problems. Amateurs try to get everything right the first time, so overloading their problem-solving capacity that they end up committing early to wrong decisions.

I like your points about home tools. I’m getting to the point where I realize that my home time is different from work time. I like working on some things so I’ll actually not by a time saving tool because what else would I have done with that time anyway? Watched TV?

Can this type of logic be applied to software development in rare cases? Or is faster always better? Kind of like the chef that used a knife instead of a food processor. He likes the feel of the knife and gets to really think about what he is doing. Maybe some thinking while coding isn’t such a bad idea.

Well I pretty much disagree with 100% of this. I am known as a decisive and the feedback I get from my team is that this is a good thing. Better an incorrect but definite decision now than a delayed decision. Sometimes it makes sense to delay a decision to get more data points, but on the whole it is better to make amends than to make excuses.

Let’s face it requirements don’t stop changing. Business processes will continue to evolve in any organization, even ones that are leaders in the industry.

If you wait until all requirements are gathered and then develop then your processes have become stale or the system will not match the processes when it is finished being developed. Before I started my current job, they had spent 1 year collecting requirements, 6 months coding and when deployed the business stopped using the system because it didn’t match their current processes.

The whole point about agile development is being agile and not rigid. You have to understand that the business is going to change, you can simply hope that it doesn’t change so much that you scrap a lot of work.

Spend 3 months collecting large requirements and identifying any process that could derail your efforts. Come up with a core design that is not so rigid that you have to scrap it if something changes (you should have identified risks). Start the development effort while final requirements are being gathered (limited requirements or identifying work arounds due to technology limitations can help reduce scope and limit customer expectations).

A lot of people like to be proactively lazy, have all the requirements collected up front. Pick and chose what is possible, and what can be done in what timeframe. Split things out in to phases, start development, not deliver on time. Have to deal with scope creep and change management. Deliver a system that is out of date and that the customers don’t use.

I would rather build a system based on what I know about the requirements. Change it as (if needed) the business changes. Deliver what I can, when I can. Keep my customers happy and keep the system up with the pace of the business.

There hasn’t been too many times that I have scraped an entire design. Perhaps a small section that I simply comment out, because they typically will want it (they just don’t know it yet).

back in the 1970s (before most of this blog neighborhood was born, alas) there was a “methodology” which preached not having finished specs and building from incomplete ones. as the “real” specs came to be, it was prophesied, the product would look like the spec. forget the name, of course, but I have these back of the brain stem memories that the worst fiascos came out of this.

as earlier threads have discussed, BDUF focuses the mind. this is a good thing.

One of my favorite quotes ever - I think it sums up the argument nicely:

"This is not to say that design is unnecessary. But after a certain point, design is just speculation."
Philip Chu

Yeah, well, maybe.

  1. what do you want it to do?
  2. understand the business as much as you can
  3. draw a line in the sand for that which you can safely deliver pretty soon
  4. build a system that is extensible, something that can be added on too fairly easily, because changes are coming (that is agile-ness)
  5. charge for changes

“Sure, you’d like to convince all your clients to sit down and really think about it, but you might as well try and convince everyone to stop fighting wars.”

Actually, most of the world has stopped fighting wars. If we could get Richard Cheney, Haliburton and their Texan puppet to stop, we might have nearly 99% of the world’s population adhering to that. Note: This blog software won’t let me put in Richard Cheney’s common name - Dic.

Now, on a more software related note, getting people to think about what they want is sure a heck of a lot easier with analysis/design tools like activity diagrams, use cases and domain models than it is with code. So, if that makes me a BDUF proponent then I guess I am. Most customers do know what they want - where the failing is will usually be in the translation of their business model/processes into requirements. They are not used to thinking in terms of requirements and therefore cannot verify that the requirements say what they want. They are not used to critiquing requirements, therefore they read into them what they want to see. The requirements change when they do realize, based on what they have seen/heard since the initial writing, that what is being built has little to nothing to do with what they want. Sure, they’ll make mistakes too but not as many as development teams will claim. Customers need something closer to their way of thinking, often a business-oriented way of thinking, in order to understand if their requirements are being properly recorded and met. Activity diagrams approximate business flows. Use cases (as per Alistair Cockburn) provide a more storylike approach to telling them what they will get. Domain models tell them what “things” in their business world are going to be available in the eventual software system. Try accomplishing that with code.

As for delaying decisions to the last responsible moment … … I went to a talk given by Mary Poppendieck on this topic and I chatted with her somewhat afterward. My interpretation of what she was saying is that delaying a decision to the last possible moment is NOT procrastination or laziness. Actually, I might argue it is hard work. You must not simply wash your hands of the decision until it is forced upon you, driving down the road to deadline oblivious to that decision. Rather you need to be constantly tracking and assessing the impact of the various decision options. How else would you know when the responsible moment has been reached or breached? You must consider in your design (and if you simply cannot think unless the debugger is doing it for you, then in your code too) so that whichever of the candidate decisions (or even new candidates that arise) eventually gets chosen due to cost/benefit, feature completeness or whatever metric, your system can rapidly (dare I say agilely) advance towards effecting that decision.

Alas, I suspect that as with XP, Agile, Test Driven Development and all the others, developers will bastardize what Mary is saying into “we don’t have to think about that because we are delaying that decision to the last responsible moment”. This will, of course, like all the other valid methodologies destroyed by the extreme interpretation by hackers, leave Mary’s idea as just more roadkill along the path to more decades of inferior, expensive and failed software projects.

Like all things, there is the finding of balance.

How do you come up with a good design when you are forced to wing it with barely defined goals?

How do you keep yourself from getting locked in to a dead end early on?

Etc…

In general, I believe there is an obsession with rapid change for changes’ sake. It’s the Red Bull Syndrome of our current culture. And it makes software that is buggy and sucks.

The best programs I’ve written had good design with well-defined specs, and a fair amount of time to work it out and test. Decisions were made early on, but again, with good design the code was not a rigid tower of uncooked angel hair pasta. Non-trivial change was discussed and dealt with, while larger changes had to be backed up with a good reason, not arbitrary whim.

The worst programs I’ve written were the ones where people could not make up there mind, changed with the daylight passing by the window, and suffered from endless last-minute decision making that chewed into rigorous testing. Yes, unit-testing, TDD, etc… Something will slip through as you are pressed for time. And the most fun of all… those long hours this half-ass approach produces.

I guess I sit in the middle of the argument for/against Agile and the like.

My apologies - I have a semantico - kind of like a typo but where the glitch was in my brain …

Where I typed “delaying a decision to the last possible moment is NOT procrastination” I should have typed “delaying a decision to the last responsible moment is NOT procrastination”

My god! Even I make mistakes! And those of you reading this blog are fortunate enough to witness the very first one!

I’m sorry, this is retarded. Decisions made early are risky, but so are the decisions made late in the project when a shitload of it is already designed and built. I’d rather see decisions made early, and only minor changes, tweaks, feature cuts, etc - later. That in my opinion is the only way to build something high quality, maintainable and coherent.

I agree with haacked, Steve.

And the space shuttle analogy is actualy a point against monolithic, “commit early” approach. When compared to the original requirement/promise, the shuttle program is wildly over budget, under performs by orders of magnitude, and suffers from a ~2% catastrophic failure rate. And you want to lable that as the way things should be done?

Let’s bring some agile ideals to the shuttle program!

Stu