3 ms·

I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when t

I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when taken axiomatically. For instance, “estimates are lies” fails to acknowledge that planning must still be done in the face of uncertainty, and engineering is the best equipped to do this. The last thing you want is for the pointy hairs to just start pulling deadlines out of thin air. But recognize it’s not about putting in time, it’s about helping the business plan and setting up the team to build things the right way. If you do this well, everyone wins, but it does require the ability to work smoothly with people who don’t share your same expertise and not treat them like idiots.

codr7 3y ago
Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort. Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms
- dasil003 3y ago
  Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you. But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in. As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
- bumby 3y ago
  To your point, most planning is bad. That doesn't mean planning is worthless when done right. It seems that most bad planning fundamentally misses the interactions between different tasks (ie it largely treats the different tasks as independent). A probabilistic approach that correlates the tasks seems to work better. Sometimes estimates are made out of ignorance or borne from an optimism bias. But sometimes they are lies, because its easier to get a project funded based on a misrepresentation, and keep it funded once the initial cost is sunk.
  - codr7 3y ago
    The point is they're always guesses, so we multiply by Pi or whatever to make reasonably sure we're not coming up short. But it's all a game, and everyone knows deep down inside that it isn't working.
    - bumby 3y ago
      >they're always guesses Maybe it's so prevalent in SWE that most are jaded, but all it means is that we are pretty bad at modeling it or simply don't care. Other domains, like aerospace, have similar problems but have much better methods to arrive at more reasonable estimates (when they care). For example, [1] gets into joint cost/schedule estimating using a more data-driven method where you can put uncertainty around it. It certainly beats 'multiplying by pi.' [1] https://www.nasa.gov/ocfo/nasa-cost-estimating-handbook-ceh/ https://www.nasa.gov/ocfo/nasa-cost-estimating-handbook-ceh/
      - codr7 3y ago
        Comparing to physical engineering doesn't make much sense to me. Part of the problem is it's all virtual, so there are no limits; part is that we're always pushing the envelope in the complexity department. Building the same software again with just a tweak or two doesn't happen very much, the reason we build new systems is often to try something so different that it's not feasible to adapt existing systems. Most of the time we have no idea exactly what we're building until we get there, even the customers usually have no idea exactly what they want. Imagine going to a car manufacturer and giving them the kind of specifications we usually get for software, I can assure you they wouldn't be able to give you a good estimate either. Research is a better comparison. How long will it take you to build a fusion reactor? Depends, right?

codr7 3y ago

Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort. Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms

dasil003 3y ago
Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you. But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in. As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
bumby 3y ago
To your point, most planning is bad. That doesn't mean planning is worthless when done right. It seems that most bad planning fundamentally misses the interactions between different tasks (ie it largely treats the different tasks as independent). A probabilistic approach that correlates the tasks seems to work better. Sometimes estimates are made out of ignorance or borne from an optimism bias. But sometimes they are lies, because its easier to get a project funded based on a misrepresentation, and keep it funded once the initial cost is sunk.
- codr7 3y ago
  The point is they're always guesses, so we multiply by Pi or whatever to make reasonably sure we're not coming up short. But it's all a game, and everyone knows deep down inside that it isn't working.
  - bumby 3y ago
    >they're always guesses Maybe it's so prevalent in SWE that most are jaded, but all it means is that we are pretty bad at modeling it or simply don't care. Other domains, like aerospace, have similar problems but have much better methods to arrive at more reasonable estimates (when they care). For example, [1] gets into joint cost/schedule estimating using a more data-driven method where you can put uncertainty around it. It certainly beats 'multiplying by pi.' [1] https://www.nasa.gov/ocfo/nasa-cost-estimating-handbook-ceh/ https://www.nasa.gov/ocfo/nasa-cost-estimating-handbook-ceh/
    - codr7 3y ago
      Comparing to physical engineering doesn't make much sense to me. Part of the problem is it's all virtual, so there are no limits; part is that we're always pushing the envelope in the complexity department. Building the same software again with just a tweak or two doesn't happen very much, the reason we build new systems is often to try something so different that it's not feasible to adapt existing systems. Most of the time we have no idea exactly what we're building until we get there, even the customers usually have no idea exactly what they want. Imagine going to a car manufacturer and giving them the kind of specifications we usually get for software, I can assure you they wouldn't be able to give you a good estimate either. Research is a better comparison. How long will it take you to build a fusion reactor? Depends, right?