The Last Responsible Moment

There are a couple of things that get solved pretty well if you just wait long enough. Of course you don’t know in advance which of the things of you have in hand will qualify for this approach, so delaying to the last responsible moment increases the chance that things just get solved by themselves :slight_smile:

some good comments but let’s face it. I hear complaints about analysts getting requirements and developers developing systems from these requirements that are obsolete before they are complete. That is almost always because no designer, or competent designer has identified from the requirements where potential variations to business process may occur so developers develop to the requirements. It’s the designer that bridges the gap between the requirements and the developers. The designer knows that the developers favorite line is “I built what they asked for” and ensures that all ambiguity is removed before the code is written. This process doesn’t mean teams can’t be nimble (not agile).

So this is basically “You Ain’t Gonna Need It” methodology. Google for “YAGNI” to read more.

An efficient decision is made with 60-70% of the information required for the decision. Any more or less is likely to cost time and/or money.

The better qualified you are for the task, the more likely you’ll consistently make a decision in the lower 60% range.

In the words of e: “Luck favors the prepared, dahhling”.

But I see the point. And I have to ask (I just HAVE to ask) where’s the balance? It’s all very well and good to say “don’t make a decision until, you know, you HAVE to make the decision.” I worked a $21mil deathmartch where that was the standard mantra. Unfortunately, in the end no one made decisions (and they got made by default) and everything went to hell.

My point is that there will ALWAYS be rework. Always, always, always, always. [stamps foot for effect] It’s a given. As Brooks said in No Silver Bullet, “build one to throw away”. Agile, BDUF, some unholy bedding of the two, there’s aways gonna be “waste”.

Aaaaand…(someone with more dev experience out there correct me if I’m wrong…) what about the times when lack of upfront planning was the direct cause of major rework. (ie: “geez…if we’d thought about this just a little more…”)

Seems to me that there’s just gonna be rework. Peopleware (Lister/DeMarco) talks about managers taking the attitude with their folks of asking how many blind alleys they’d been down recently. And making sure that “none” is not the right answer.

Hindsight is always 20/20.

Some decisions need to be made up front. Can’t continue without them. Some decisions can wait.

And it seems there’s a damn few folks who can always tell the difference.

(yes, I use my compressor probably every other week, assembled my kids’ bikes with the metric socket set, and the wet-dry vac…we’ll, it’s just a happy thing. The $500 dewalt planer, on the other hand, has gotten minimal wear…)

Hard work pays off later, laziness pays off now, right? :slight_smile:

This is why I liked storyboarding so much, especially when I’d been tasked to develop GUIs. A blank wall and lots of postings, regularly updated, that people can move around and look at where we are, where we’ve been, and where we’re going.

When we didn’t know where we were going, someone unrelated to the project often wandered by and identified something we all missed. The meeting that followed the “gee whiz” moment usually came up with the responsible decision.

This is too uncool for the company where I work now. We have to have a wiki. Back to ad hoc development…

I’m guessing you are pulling everyone’s chain a bit, no? :slight_smile:
But you should have called it “The Walking on the Edge” software development model, that sounds much better :slight_smile:

I have a fair number of unused tools in the garage. Every now and then I toss ones that are clearly not getting used.

They are there because I do not want to have to add the overhead of buying a tool on top of a rush home project. If I have to go out and buy a level, a drill, or a screwdriver to hang a new TV, I have just pushed that project out from an easy evening to staying up late. I would rather get it done when I have the need.

Put simply, putting off a decision may be a good idea if you lack sufficient information, but may really bite you if you suddenly need to use the decision, without the time to make it.

Scott

I alway referred to this as the Bachelor Rule of Design - avoid commitment until the last possible moment. And lest you think that derogatory, I consider to be an optimal approach for most systems I design.

I’ll add another consideration, that bears on design pardadigm. There are two types of software developer (those that divide…): those that build VAR systems, and those that don’t. The fundamental difference is that those that do are implementing a superior (at least, that’s what claim to sell) business method; the others are merely trying to placate some users, acquired somehow.

If you’re selling a software manifestation of a superior business method, then you know what the software is going to do, BDUF is the sane approach. Who ya gonna ask, your evil twin? Spolsky operates from this position. The job is to convince folks to buy your superior business method; the software is along for the ride. SAP is the canonical example. They’ve managed to turn mission critical software for MegaCorps (what had been a differentiating vector for such organizations) into shrinkwrap. It is mind boggling.

I’ve worked with and for VARs aiming at the mid-size market, and it’s a tough thing to do. SAP pulled a rabbit out of the hat. They’ve told Ford, et al, how to run their businesses. Hmm. Maybe it was all a EuroConspiracy???

If you’re working for a MegaCorps satisfying captive users (and you’re a captive developer, too); then you don’t know the superior business methods. Your users will make damn sure you know that. It is a poisonous situation, generally. Been in that one, too.

I agree with Steve, this is madness. As a software designer, I run through many decision trees as early as I can in the process so that I have many contingency plans as the requirements change throughout the SDLC. It’s called risk mitigation as developing software is risky business. Software development is like playing Beat the Clock - we don’t even have enough time to decide anything let alone waiting for the “last responsible moment.”

Margherite made a great comment on storyboarding. Heavily used in the creative process for making multi-million dollar movies to mitigate the risk before the shoot. We in the software world can learn a thing or two from the film industry.

Tools? What tools. The tools we have in the software world today are equivalent to the hammer and chisel from the 19th century. That’s one of the reasons why we have all of this process and methodology hoo haa, along with the embarrassing names (I hope history won’t laugh at us too much). If our tools enabled us to build software intensive systems in a month or two, you would never hear about “agile”.

Be prepared, I think is a great motto for the software world. A fellow software developer, who happens to be mountain climber, had a modified motto, be prepared or die. While no-one is going to die developing software (I hope not!), we could do a lot better job by being prepared to deal with the only constant in our world – change.

The difference between “as late as possible” and “as late as responsibly possible”, from personal experience:

As late as responsibly possible:
Looking at the Haynes manual to find that I need to buy a set of small metric sockets, before taking the driver’s side-view mirror off of my car.

As late as possible:
Driving to the hardware store to pick up a set of small metric sockets, with my driver’s side-view mirror dangling by a bundle of wires, because I read the manual as I went along instead of looking it over before beginning.

1 Like

Now that’s freaking hilarious.

“If you’re working for a MegaCorps satisfying captive users (and you’re a captive developer, too); then you don’t know the superior business methods. Your users will make damn sure you know that. It is a poisonous situation, generally. Been in that one, too.”

I’d been thinking this all along. “All” you have to do as a VAR is build, and sell, your “better mousetrap”. If you’re building for an in-house group, you have to build the exact mousetrap they want and at any given time they feel they have the right to change the mousetrap in any way they like because they “pay your wages”.

I both agree and disagree with ALL of this. I tend to be a decision maker, and to run the decision tree early and often. But decision in any project can also be like code you are working on in a svn tree: why sould you COMMIT before anyone else needs to use what you are working on, or it is mature?

That would be: decide early, but do not tell your decision before someone needs to know :slight_smile:

there are studious approaches to decision making in organisations

I’d note that the key word here is “responsible”. While deferred decision-making is, in general, a good thing, I’ve seen a few too many Agile Addicts wait until the last possible moment (or later), as opposed to the last responsible moment.

This is a good philosophy as long as it’s kept in check with a solid understanding of which decisions can’t be put off, which requires an ability to actually analyze or at least estimate the potential impact of those decisions rather than simply assuming that they don’t matter now. There’s a fine line between deferred decision and indecision!

Sam, where did you get the 60-70% number? That sounds about right.

My experience has been that chasing down that one last risk and getting someone to commit to that last vital decision is a complete waste of time. Let’s face it, your customer can absolutely sign a contract in blood that says that the tire swing will not actually contain a tire, has pictures of it without a tire, shows use cases without a tire and then when it’s built, their boss asks where the tire is and you get nailed to the wall. That’s life in the biz, and you better find a way to stick that tire in somewhere.

I wonder if people from Scunthorpe are able to post?