4 ms·

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practice

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so you're not meeting your estimates. Then they admit that "they delivered something different" - so you're not building what you promised. Then they admit that "they "spent too much time on non-deliverables" - so you're spending the last months pre-deadline working hard to catch up on something that is already behind schedule and doesn't match the original spec. But it's all OK because they kept the stakeholders updated with frequent communication and conversations...basically the same result as if they had not estimated a date but instead focused on iterative delivery and constant feedback with the customer. Sound familiar? > Suddenly, the whole team became focused, distractions were all gone, and we moved at a faster pace than I've ever felt the team do so. Why was the team not focused & distraction free from the start? How could you achieve this efficiency without needing a deadline hanging over your heads?

mobjack 7y ago
When you keep stakeholders updated early, you force them to make hard decisions about their product so you know what to prioritize. It makes everyone focus on what is most important. Are those features really necessary for the release? Can we change the requirements to accomplish the goal easier? Is it important enough that we should delay it? Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line. I do that along with every other engineer I know. It is human nature.
- deleted 7y ago
  [deleted]
- spoondan 7y ago
  You don’t need a deadline to establish priorities and ensure the team is focused on those priorities. Nor does a deadline actually prevent procrastination. We all have had homework due that we have rushed to finish because we were watching TV, playing games, out with friends, or whatever. So too with software engineering. Anyway, if you are using sprints, there actually are due dates. It’s just there are a lot of them occurring in rapid succession, and we don’t commit to what we’ll finish in the following due date until after the impending one.
- jasonpeacock 7y ago
  > Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line. Why is the threat of a deadline required to ship product?
k__ 7y ago
I really hate this estimation crap. We do it at the start, people change their mind 10 times and then we deliver something different and it's considered business as usual. But if I suggest just once that we cut the estimates out, people get angry and afraid. As if they all WANT to be lied at...
- jcelerier 7y ago
  > As if they all WANT to be lied at... well... I mean, that's the whole point - end game is to have engineer-sourced figures that you can show to your banker so that they put cash in your account and become subject to the opportunity cost paradox when it's too late and you have to move your deadlines.
  - k__ 7y ago
    Everyone wants to play the software game, but no one wants to look the risk in the eye. You tell people the truth and they call you unprofessional for it.
nilkn 7y ago
As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. Some folks tend to think that if a plan is produced but not followed exactly, then it wasn’t worth producing the plan. But actually having produced the plan is sometimes what makes it easy to deviate when complications arise. If a new decision is made that affects the plan, everyone can see exactly what the compromises are and be on the same page.
- pjc50 7y ago
  This is Eisenhower's "plans are useless but plans are vital"
  - p1necone 7y ago
    I think you mean "plans are useless but planning is vital"
  - xtracto 7y ago
    There is another saying in modeling and simulation: All models are wrong, some are useful. As an Eng. Leader I use planning and estimates to communicate with other stakeholders. One thing the majority of people fail at is giving variance when providing a forecast/estimate. If someone asks me to get an quick estimate for developing something I'll give them a range with wide margin, around the avg time I think it will take. If they want to reduce that range, then I need info to understand the requirements better. Problem has always been that what engineers provide as an ESTIMATE, business takes as a deadline. So, engineers: always add buffer to your estimate.
- bsder 7y ago
  > As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. I always despise these kinds of exercises. We know how to roll up estimates correctly with statistics--even moreso if we have historical data. The problem is that management always hates the accurate number. And that's where the dysfunction sets in. While everybody else rolls things up "normally", I almost always roll up an "accurate" timeline and try to inform people up front. It rarely wins me friends, but it sometimes protects my team when things are going haywire later.
cynusx 7y ago
I think you are assuming that just because you estimated the work to be done that that would lead to a hard deadline on that day. In my experience hard deadlines are a bad idea but estimating work is also necessary to allow the organization to plan what to build. It also creates a beneficial cycle where stakeholders will reduce the feature set because typically smaller projects get front-loaded in the development roadmap to deliver value faster
- spoondan 7y ago
  I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response? Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows they aren’t. NASA isn’t going to launch a vehicle that they know isn’t ready. Video games, hardware, and movies get delayed. Our software project can have features cut or the release date changed. And, for the most part, it’s okay. That deadlines are “soft” in some sense doesn’t undercut any of the substantive points made against them, nor does it actually evidence any of the claims made for them.
  - cynusx 7y ago
    My point is that there is a difference between giving an estimation of time and a commitment to deliver over a certain time. The parent assumes that just giving the estimate is the same as making the commitment. The distinction between hard and soft deadlines is not relevant to my argument.
    - Scarblac 7y ago
      Theoretically, a perfect estimate means you'll be under it 50% of the time and over it 50% of the time. No bias. Still management definitely feels something has gone wrong when you say at least half the projects will be over estimate.

mobjack 7y ago

When you keep stakeholders updated early, you force them to make hard decisions about their product so you know what to prioritize. It makes everyone focus on what is most important. Are those features really necessary for the release? Can we change the requirements to accomplish the goal easier? Is it important enough that we should delay it? Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line. I do that along with every other engineer I know. It is human nature.

deleted 7y ago
[deleted]
spoondan 7y ago
You don’t need a deadline to establish priorities and ensure the team is focused on those priorities. Nor does a deadline actually prevent procrastination. We all have had homework due that we have rushed to finish because we were watching TV, playing games, out with friends, or whatever. So too with software engineering. Anyway, if you are using sprints, there actually are due dates. It’s just there are a lot of them occurring in rapid succession, and we don’t commit to what we’ll finish in the following due date until after the impending one.
jasonpeacock 7y ago
> Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line. Why is the threat of a deadline required to ship product?

k__ 7y ago

I really hate this estimation crap. We do it at the start, people change their mind 10 times and then we deliver something different and it's considered business as usual. But if I suggest just once that we cut the estimates out, people get angry and afraid. As if they all WANT to be lied at...

jcelerier 7y ago
> As if they all WANT to be lied at... well... I mean, that's the whole point - end game is to have engineer-sourced figures that you can show to your banker so that they put cash in your account and become subject to the opportunity cost paradox when it's too late and you have to move your deadlines.
- k__ 7y ago
  Everyone wants to play the software game, but no one wants to look the risk in the eye. You tell people the truth and they call you unprofessional for it.

nilkn 7y ago

As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. Some folks tend to think that if a plan is produced but not followed exactly, then it wasn’t worth producing the plan. But actually having produced the plan is sometimes what makes it easy to deviate when complications arise. If a new decision is made that affects the plan, everyone can see exactly what the compromises are and be on the same page.

pjc50 7y ago
This is Eisenhower's "plans are useless but plans are vital"
- p1necone 7y ago
  I think you mean "plans are useless but planning is vital"
- xtracto 7y ago
  There is another saying in modeling and simulation: All models are wrong, some are useful. As an Eng. Leader I use planning and estimates to communicate with other stakeholders. One thing the majority of people fail at is giving variance when providing a forecast/estimate. If someone asks me to get an quick estimate for developing something I'll give them a range with wide margin, around the avg time I think it will take. If they want to reduce that range, then I need info to understand the requirements better. Problem has always been that what engineers provide as an ESTIMATE, business takes as a deadline. So, engineers: always add buffer to your estimate.
bsder 7y ago
> As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. I always despise these kinds of exercises. We know how to roll up estimates correctly with statistics--even moreso if we have historical data. The problem is that management always hates the accurate number. And that's where the dysfunction sets in. While everybody else rolls things up "normally", I almost always roll up an "accurate" timeline and try to inform people up front. It rarely wins me friends, but it sometimes protects my team when things are going haywire later.

cynusx 7y ago

I think you are assuming that just because you estimated the work to be done that that would lead to a hard deadline on that day. In my experience hard deadlines are a bad idea but estimating work is also necessary to allow the organization to plan what to build. It also creates a beneficial cycle where stakeholders will reduce the feature set because typically smaller projects get front-loaded in the development roadmap to deliver value faster

spoondan 7y ago
I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response? Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows they aren’t. NASA isn’t going to launch a vehicle that they know isn’t ready. Video games, hardware, and movies get delayed. Our software project can have features cut or the release date changed. And, for the most part, it’s okay. That deadlines are “soft” in some sense doesn’t undercut any of the substantive points made against them, nor does it actually evidence any of the claims made for them.
- cynusx 7y ago
  My point is that there is a difference between giving an estimation of time and a commitment to deliver over a certain time. The parent assumes that just giving the estimate is the same as making the commitment. The distinction between hard and soft deadlines is not relevant to my argument.
  - Scarblac 7y ago
    Theoretically, a perfect estimate means you'll be under it 50% of the time and over it 50% of the time. No bias. Still management definitely feels something has gone wrong when you say at least half the projects will be over estimate.