In days of yore a man used to prove his bravery by a mighty quest for a fair maiden, the slaying of a ferocious dragon or by acts of great swordsmanship on the battlefield. Sadly in modern times these opportunities rarely present themselves to the average software developer. But fret not stout of heart – there are still ample opportunities for bravery without moving away from your monitor. Simply give an estimation of how long a software project is going to take using the following methodology.
I truly believe that software estimation is blackest of all the black arts in software development. Entire books are (quite rightly) written on the subject.
The best and simultaneously the worst advice I’ve have ever read about estimation comes from Crash – Learning from the World’s Worst Computer Disasters. Quite simply - sit down in a quiet room with a bit piece of paper and a large mug of coffee and truly and honestly work out how long you believe the project will take. Miss nothing out. Remember the testing, remember the deployment, remember the reworking, remember it all. Then TRIPLE it. No matter how bleak the answer looks – bravely go out and tell your project manager. He/She will not thank you for it. They will request re-evaluations, ask second opinions and doubt your sanity. You may be sidelined, sneered at or send off in exile to the build team. You will be tattered, torn and unloved but you will be correct.
If you are brave then try this. I did once and it caused a career damaging fight between the head of development and the project manager. The project manager left, the head of development sulked but the work was delivered in the (tripled) timescales that I said. I was unloved but correct. I was brave. I never did it again.
As an addendum to this – a far better way of estimating projects would be to actually start to build historic data in your company as base predictions on that. Steve McConnell gives excellent advice on this in Rapid Development. The moral of the above little anecdote is that it’s not enough to be correct; you have to be correct and believable - and that takes evidence.
As an addendum to this – a far better way of estimating projects would be to actually start to build historic data in your company as base predictions on that. Steve McConnell gives excellent advice on this in Rapid Development. The moral of the above little anecdote is that it’s not enough to be correct; you have to be correct and believable - and that takes evidence.
No comments:
Post a Comment