I was talking with a new member of my team about a new project’s first feature. The feature is kind of a prototype for the application, a full-stack slice of the application meant to get quick a feedback on some initial design choices. When my colleague asked me:
How long will it last?
I immediately answered:
I don’t know : how long do you think we will have to go back on our choices before we eventually get to a satisfying design? When will we be satisfied of our best bad idea?
I can’t remember the last time I have seen a developer satisfied of its first draft, or an architecture being satisfying right from the start.
The work of a developer is rather similar to the work of a writer. I recently heard French writer Bernard Werber saying that, before he can send a new book to its publisher, he must rewrite it entirely several times. He was saying that he rewrites the book without using previous versions : he remembers about interesting parts and can easily get rid of less interesting ones.
Developers follow the same approach : the first thing is to find an answer to a specific problem, which is telling a story in a way. When the problem is solved, which might not be done with the first try, developers deal with the style : is the story a little bit too long? is it easily readable? are all these characters really necessary? should we split this paragraph? etc. This is called refactoring.
So if we ask Bernard Werber to tell us how long it will last to write his next book, he will certainly answer that he cannot answer. At best he could try a pragmatic approach : “For 8 of my 10 last books I had to rewrite them at least 15 times but never more than 18 times. Moreover writing a book once never takes more than X months. We could then estimate that there is 80 % chance that I finish my next book between FOO and BAR.” Who would blame him?
Nevertheless nowadays people keep asking estimates to knowledge workers – developers. It might be story points, ideal days, or even month/man or real days. The developer must hazard himself into the dark art of crystal ball divination : he must first analyse the feature, estimate the development time of what he just imagined, predict how long it will take to get to a satisfying result – which may mean finding a better idea and implement it, predict interruptions, waiting times, bugs, perform a risk analysis, etc. It would be easier to roll a pair of dice.
I think this is the main difference between Lean and Agile Software Development : pragmatism. Making random estimates is pure waste of time, and taking decisions based on those estimates (alone) is a major risk for the project. That’s why leanists and kanbanists prefer statistical approaches and modelisations : taking decisions based on facts. Thus I should have answered something like:
Before you get in the team, the cycle time of 85% of the features was less than 8 days, and less that 12 days for 95% of them. In my experience, I can tell you that the first feature of a project is always longer than any other. Now that you are in the team, considering the fact that we must teach you how we work, we can say for sure that it’ll be even longer than usual. Nevertheless, it is impossible – I mean statistically – that it takes more than 14 days.
This post is an adaptation of http://matthiasjouan.fr/combien-de-fois-penses-tu-te-tromper/
