Seven Principles of Lean Software Development - Defer Commitment

November 6, 2008 by Przemysław Bielicki

Picture courtesy of _fabrizio_@flickr

No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?

This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.

In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Schedule Irreversible Decisions at the Last Responsible Moment

You have to "abolish the notion that it is a good practice to start development with a complete specification" - basically They Aren't Gonna Read It.

I will give you a non-technical example (I think it's very popular but I will refactor it for my needs). Last year I was on my honeymoon in Spain - before going there I and my wife made a "big picture" plan what we want to see. We knew we were going there for three weeks and we were able to roughly assess how many places we are able to visit (in a decent pace - not travel-agency-rush-style). But we didn't have a full specification like: on Monday we are in Barcelona, Tuesday in Teruel, Wednesday in Madrid, etc. We just knew when we arrive to Spain, that we start visiting from Barcelona, when we have our flight back and what we want to see.

After few days in Barcelona we took a car and drove along the Spain to visit the rest of this amazing country. And we were planning our trip day after day - sometimes it was a bit stressful but we did it. We saw more than we planned and we had a really GREAT fun doing it. We were not attached to the plan - and I know we would have many problems with the plan because I made one just in case :) We wouldn't be able to see some places because we didn't know about many Spanish specifics - we learned them during the trip and we were able to adapt in an agile way.

The same is with software: "concurrent development saves money, it saves time, it produces the best results, it allows you to make decisions based on the most current data". You should know where you want to go but you don't know the road very well. You will be discovering it day after day - the most important thing is to keep the right direction. You don't necessarily have to drive highways all the time - maybe you should sometimes go with rutted roads - it can be faster and you may "see" and learn more things.

Break Dependencies

If you are worried about the dependencies of different components of your software - break them. Your components should be coupled as loosely as possible to enable implementation in any order. Of course some components will depend on other but it is often useful to rethink the architecture and accept dependencies only when there is no other sensible option.

Sometimes it would be useful to move some pieces of software from one component to another in order to remove dependencies. It's a very instructive exercise - you will merge few components in one or split one big component into smaller ones removing number of dependencies. Don't be afraid of doing this - you have REFACTORING (watch out - there are two links), right? But do it only when you arrive to the point you are sure you need it.

Loosely coupled components will pay off - you will be able to implement them simultaneously, thus you will deliver the whole product faster and your components will be probably reusable and ready to use in other projects.

Maintain Options

Good (but not always cheap) thing is to develop multiple solutions for all critical decisions and see which one works best. It can be sometimes hard, expensive and time consuming but you should decide what is cheaper in the long run. Robert Harris in his novel "Pompeii" wrote this: "What was leadership, after all, but the blind choice of one route over another and the confident pretence that the decision was based on reason". Do you want your decisions to be blind choices? If not you should invest some time and money in understanding the impact of each critical decision you have to make.

For all other (non-critical) decisions you should keep your code change tolerant. Remember that "change is the only constant". Make your code ready for changes - easy changes, and don't hesitate to change it.

Defer Commitment

I hope pieces of advice given above will make it easy to understand "Defer Commitment" principle. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Other articles in this series can be found here:

1. Respect People
2. Deliver Fast
3. Optimize the Whole
4. Build Quality In
5. Create Knowledge
6. Eliminate Waste

Permalink