The Last Responsible Moment

In order to decide when is the right time, you have to know all your options, and what the cost of each one will be (no need for great precision, but to have an idea).
This is the only way that allows you to really choose. Otherwise, it is not you making the decision.

Back to the tools thing: if I know I will need to cut some wood for this project, I know I will need a tool for that. I consider all the wood-cutting tools, put in balance the price, how easy is to find the tool (do you have to order it?), if I know how to use it, how long will I use it, what is the productivity with the various tools.
And then I can wait with the real decision until I find out more.
I can even do the decision in steps. In two days I will have to decide if I order that chain-saw from Japan. If I decide not to buy that, I can wait two more weeks for the other sub-decisions, because the other tools are available at Home Depot.

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.