We are often asked as software professionals to estimate, often 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.
Scheduled on Friday from 14:45 to 15:00 in Room 5
James has worked in software since the 1990s when TDD was something you studied but never did, pipelines were for carrying oil and "Agile" and "Lean" were words used for describing athletes. James worked for 9 years in a startup where he learned the hard way about CI, CD and splitting the monolith. In 2015 he started a new life as a consultant, spending 4 wonderfully happy years at ThoughtWorks. In July 2019, he started a new adventure at Codurance where he is a champion of software excellence through solving the organisational problems.