We are often asked as software professionals to estimate, usually with a laughable level of precision, the time for a whole product at the very time that we have the least idea how long it could possibly take. Unsurprisingly these estimates don't turn out to be very accurate. Why do people think they need these estimates? What value do they think they get from them? In my entire 20+ year career in software delivery I have rarely seen estimates used positively, for example to help inform a business plan. I have only ever seen them used negatively, as a kind of post hoc pseudo contract that the development team inevitably broke. In this talk I will explain what I think are the only times that estimation is justified and what you can do to prevent getting forced into a binding contract that you not only didn't sign but that you didn't realise even existed.
James has worked in software since the 1990s, when TDD was something you studied but never did, Agile and Lean were words used to describe athletes and pipelines were for carrying oil. After working in a startup for 9 years he started a new life as a consultant and now spends his working days at Codurance trying (and occasionally succeeding) to effect positive organisational change through enabling others to deliver high quality products.