To a developer, estimates may seem useless. Which is understandable given how they’re often abused as a bludgeon. I’d argue that management that holds developers to hard deadlines based on estimates is dysfunctional.
“Software should be built in the order that value is created.” It’s difficult to argue against that, but I’m going to try.
Maybe instead of being built in order of value created, it should be built in order of highest to lowest ROI. But to understand ROI you need to know not only the value added but the cost of building it. And the cost includes both the developer hours (direct investment) and the opportunity cost (what else would we be able to build during that time if we didn’t build this?). Both of which require having some idea of how long/how much effort it will take.
If we build Foo now, will that push Bar back by a week? Or by 6 weeks? Or by 6 months? In an organization with sensible leadership, that will determine whether it’s worthwhile to build Foo now or later or not at all.
1 comment
[ 1.8 ms ] story [ 15.5 ms ] thread“Software should be built in the order that value is created.” It’s difficult to argue against that, but I’m going to try.
Maybe instead of being built in order of value created, it should be built in order of highest to lowest ROI. But to understand ROI you need to know not only the value added but the cost of building it. And the cost includes both the developer hours (direct investment) and the opportunity cost (what else would we be able to build during that time if we didn’t build this?). Both of which require having some idea of how long/how much effort it will take.
If we build Foo now, will that push Bar back by a week? Or by 6 weeks? Or by 6 months? In an organization with sensible leadership, that will determine whether it’s worthwhile to build Foo now or later or not at all.