i believe one of the culprits for software taking so long is planning. this is alluded to in marty cagan's excellent book _Inspired_. first, the caveat: a soft

i believe one of the culprits for software taking so long is planning. this is alluded to in marty cagan's excellent book _Inspired_. first, the caveat: a software dev project will take up as much time as is allotted to it. when you have more than enough time allotted for a project, most people either spend more time in research or allow themselves partial implementation paths of multiple solutions to help decide which one is best. on the other end of the project, every project can be polished forever. so dev projects will take as least as much time as has been allotted to it. when we go through the planning process, it usually follows something like this: 1. dev estimates how many "points" (which translates into time in most peoples mind) to allot to a task. dev then pads it to account for dev optimism and wanting to make sure they have the chance of meeting the "committment" 2. program/project/product manager pads the number a bit further because they've been burned in the past on dev optimistic estimates and it's better to underpromise and overdeliver 3. dev proceeds on the task with the bloated estimate baked in and the task takes the full time allotted to it. it's baked inefficiency. part of the problem is the concept of "committment" for estimates. good scrum organizations have changed that term to "prediction" instead of "committment" since this has been such a big problem. but even that isn't enough to solve the political capital lost when you "predict" wrong. i think that any estimation above "t-shirt size" is going to bake this inefficiency into your process. the solution is less planning and more doing.