Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool



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


Comments

AlanAJ said:

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.

# April 11, 2007 11:27 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News