Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Deciding as Late as Possible
What does the phrase ‘Deciding as Late as Possible’ mean in reference to software development? Does it mean that you don’t have to make decisions? Does it mean that you can procrastinate until some point in the future to make a decision? No, it means that you defer making critical or risky decisions until the very last moment. There are many different reasons why this approach can be successful, as well as there are many different reasons why individuals are afraid to take this approach.

‘Deciding as Late as Possible’ means that you don’t make a decision about fine details until the details are needed. On person that I work with refers to this as ‘Just In Time Requirements’, which if done right can lead to much better, less risky decisions being made.

What happens if you make the decisions early?

  1. You may miss a key aspect of the problem because you focused on the fine details too early.

    What do I mean? If you attempt to drill down to the fine details too quickly you could make the mistake of overlooking the obvious at the expense of finding the not-so-obvious?

  2. You may over complicate the situation by trying to look at every known aspect of the problem.

    What do I mean? As we know, Agile advocates solving today’s business problems today, and leave tomorrows problems for tomorrow? We will know better in the future what we really need and creating simple code now will allow for the code to be easier extended later.

  3. You may expend a lot of unneeded energy up front trying to solve the problem before you know the full extent of the problem, or until you have explored alternative solutions.

    What do I mean? As developers we tend to want to solve problems as they occur, which may not be when they need to be solved. This leads to waste, and does not deliver customer value.

What happens if make the decision late?

  1. You can come up with the simplest solution to meet your current need.

    What do I mean? By only trying to solve the problem at hand, and not all possible scenarios, the developer can write simpler code, which leads to more extendable, refactorable code. This also tends to avoid adding extra features ‘just-in-case’ they are needed, and only the features you know you will need.

  2. You have time to explore other alternative solutions at a high level and make the best/most informed decision as possible.

    What do I mean? As we know, software development is not an exact science. There are many ways to solve any problem. All of them may be correct, but some may be better than others. If we avoid drilling down to the fine detail early, we can explore more solutions at a high level and choose the solution that works best for that particular situation.

  3. You can mitigate risks by not the wrong decision too early.

    What do I mean? If you attempt to dive down to the fine level too early, you may head down the wrong road too quickly. If you are attempting to make a critical decision without all the facts you can force yourself into a corner and not be able to get out.

Finally, readily changed decisions can be made and changed, so if you make one too early, though it's inefficient, it's not big trouble. Decisions with a large cost of change are exactly the ones that should be deferred as long as possible but no longer.

Please let me know what you think

Posted 09-27-2006 6:35 AM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

AlanAJ wrote re: Deciding as Late as Possible
on 04-11-2007 11:27 AM

I call this "Just-in-Time Requirement Specification".  I'm very particular that there be no s at the end of Requirement, since each requirement should be treated individually.

It's such a simple and effective discipline.  If you know how detailed each requirement needs to be now and by when more detail will be required, you are in control of the requirements and, in all probability, the project.  If not, not!

You don't mention the biggest advantage...  The sooner you start, the sooner you'll be finished.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)