7 ms·

I don't think your solutions will work. It's impossible to get time estimates right for building software. Too many variables in solving the problems, not only

I don't think your solutions will work. It's impossible to get time estimates right for building software. Too many variables in solving the problems, not only in writing code and testing it, but also including open office disturbances and meetings. I understand product owners and businesses wants estimates but software engineering is not making a car. Forcing programmers to estimate their every task makes for a very bad work environment. They are not robots.

padobson 9y ago
My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. It requires more project management, but it's much easier to quarantine problems and explain them to stakeholders. My rule of thumb is 4 hours. If you think it will take longer than 4 hours, it should be broken down. Ideally, most tasks will have estimates of 1 hour. That way, when a 2-hour task requires 2 weeks to complete, you can point to the specific task and its challenges. It provides an easy explanation for why the release was late, why the requirements were too ambitious, etc.
- ethnicify 9y ago
  This is micromanagement. You're describing micromanagement. Engineers do not need to be managed down to the hour. Good grief.
  - padobson 9y ago
    It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less. The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required. Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.
    - 123212321 9y ago
      This sounds like pure misery. No self respecting good developer would work under these conditions.
    - doseofreality 9y ago
      So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long? If this isn't micromanagement, what would you define as micromanagement?
      - beegeezuz 9y ago
        Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.
        fao_ 9y ago
        Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~
        chrisbennet 9y ago
        A month is too long to wait. Break it down into smaller units... ;-) I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.
    - drharby 9y ago
      Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it
    - aje403 9y ago
      I would definitely consider a gulag over this
  - veidr 9y ago
    In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes. However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive. I feel like I have, over the years, sometimes crossed that line. (And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)
    - deleted 9y ago
      [deleted]
    - Retric 9y ago
      Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless. The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.
      - shagie 9y ago
        An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.” Giving single numbers for an estimate with uncertainty is bad for all parties. Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.
        Retric 9y ago
        That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%. AKA Y is much higher when you deal with low hour estimates. This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.
  - janlaureys 9y ago
    This gives me PTSD to a consulting job I had as a web developer where every 15-30 minutes the project manager would come up to my desk to ask what I've been up to and what I had achieved (in the last 15 minutes). He'd also get upset when the feature I was working on wasn't finished yet since the last meeting.
    - matte_black 9y ago
      With an interruption every 15 minutes, sounds like you would never reach a state of flow.
      - ImSkeptical 9y ago
        My own strategy with such people is to bore them into never speaking with me. Every such question, I'll take a moment to compose my thoughts, and then begin explaining, as thoroughly as possible, in a monotonous cadence, exactly what's been going on. I'm also sure to always add that reporting on progress is consuming a significant amount of time, especially because it is an interruption. I also repeat any instruction given to me in different words, and describe what I'm currently working on, what I think the priority of the new thing should be relative to current tasks, and ask if they agree with me. In my experience, people simply lack the will to repeatedly endure lengthy and dull interactions. I can tell they zone out soon after I start talking, and I keep lashing them with boredom until they learn to not interrupt me. I'd suspect the kind of person who asks for an update every fifteen minutes is doing so out of a minor sadistic impulse, rather than for any legitimate reason. If so, the important thing would be never to appear bothered by it. That would be my strategy at least.
    - EKLM-ZK88 9y ago
      I've personally witnessed the VP of product stand over our senior engineer's shoulder while he tried to debug some serious bug that we couldn't reproduce in dev/stage for hours until it was done. That same engineer also had the CEO stand over his shoulder and actually ask "You don't mind if I stand here and watch do you?" The same CEO constantly brags about his "10 years of experience building companies with successful exits"(10 years of experience vs 1 year of experience ten times), and calls his company the "Amazon of the south". Reading this article gave me flashbacks, but it does help to know that it wasn't just that company.
  - ajb257 9y ago
    It's not micromanagement. It's planning. There's nothing wrong with those tasks having no-user facing changes, or giving all the tasks to acheive a higher-level goal to one developer. However, going in and making those tasks forces you to think over the problem properly and come up with a game plan. If you don't know a given approach will work, sometimes that's best to timebox some experimentation time (say an afternoon), but then you can also say to your PM/EM 'ok, we need a little time to work out how long it's going to take', and decisions can be made accordingly as to priorities. Very little of being a software engineer is about writing code. That's just typing. The skill is being able to come up with a coherant plan to solve a problem. That's why architects don't tend to write a lot of code.
- maxxxxx 9y ago
  This works only if you do things that are well understood beforehand. If you are doing things that require a lot of research and experimentation this project plan falls apart quickly.
  - mateo411 9y ago
    Correct. If you have to do research and experimentation before you can make good estimates, then you need to allocate time to do that. I use the term discovery phase to describe this. You give the discovery phase a certain amount of time to complete, it should be from a few days to 2 weeks. The deliverable at the end of discovery phase is a document. The document explains what experiments were run and what we should do next.
    - maxxxxx 9y ago
      This still rubs me the wrong way. I guess I personally don't like micromanaged environments. I don't want to have to explain every little step and report back all the time to people whose only interest is the deadline. I prefer to be treated like an adult who can be trusted to do the right thing to get to the goal quickly without being supervised at every step. But I know plenty of people who need constant monitoring and handholding.
      - atridan 9y ago
        I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task. This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.
        maxxxxx 9y ago
- blauditore 9y ago
  I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time. My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).
  - hrktb 9y ago
    > If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. This seems to be a concept so hard to grasp for non technical managers. By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions. Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.
- andyjohnson0 9y ago
  > My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. The problem with this is that the time required to complete all the pieces is almost never equal to the sum of their estimated durations.
- zintinio5 9y ago
  I would quit this team.
- expertentipp 9y ago
  My current team is estimating up the to one hour and afterwards reporting the work with an hour resolution. It's low cost center squeezing the last cent form the engineering workforce. We are not asked for opinion or for a decision but to implement the tasks distributed by architects and Scrum masters. I'm quitting this place with the first opportunity possible and before taking all holidays until the end of the notice period. I will not even say goodbye.
  - s73v3r_ 9y ago
    "taking all holidays until the end of the notice period" Do you mean bank holidays? Cause regardless of how you feel about your company, you should always take those. Rest and disconnect from work are important, especially in environments where you really like the work or the job, and the risk of overheating is much greater.
    - vanilla_nut 9y ago
      Presumably he means taking his vacation days so he doesn't have to put in any days of work in the 2 weeks after he puts in his notice. I'd guess he isn't American -- the term "holiday" is interchangeable with "vacation" in most of Europe, for instance. That being said, your point about bank holidays is a good one. Never give your company free labor -- they'll never give you free capital.
      - EKLM-ZK88 9y ago
        I would be careful with this, my last employer refused to pay for unspent vacation days, and if you put in your notice or thought the individual was likely to quit they wouldnt approve your PTO requests. I don't know if this is legal (South Florida), but all the information i find online for this state say that the employer is not required to pay out your time (varies by state).
    - expertentipp 9y ago
      I mean withdrawing entire remaining annual leave to spend in the office the minimal time possible during the notice period.
- laythea 9y ago
  1 hour tasks! Sound like a recent working environment I was in where I witnessed a poor permanent employee driven to booking 10 mins to a task by this mentality from management down. Also, none of them spoke to each other due to the time-micromanagement. No thanks.
- AFNobody 9y ago
  I think you are overdoing it simply because per-hour estimates are extremely time consuming to produce and borders on micromanagement. Realistically, tasks should be grouped into roughly day-sized estimates for any long project with an equally large QA pool possibly run in parallel. Granularity only gets you so far before the returns diminish to the point of worthlessness. Imho anyway.
scottinseattle 9y ago
Are you sure it's impossible to get time estimates right for building software? What do you even mean by that? What methods have you tried and in what context(s)? How much data substantiates your claim? I'm not trying to be a dick, but there's a lot of shit that passes for wisdom online which boils down to, "I tried it once and it didn't work for me." Most software engineers I've spoken to, when challenged, admit they don't know shit about software estimation techniques and haven't even heard of PERT, Wideband Delphi, work breakdown structures, etc, etc. At least read the book Software Estimation: Demystifying the Black Art before you go around saying that it's impossible to get time estimates right for building software. I think if you did, you would be a lot less cavalier about it.

padobson 9y ago

My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. It requires more project management, but it's much easier to quarantine problems and explain them to stakeholders. My rule of thumb is 4 hours. If you think it will take longer than 4 hours, it should be broken down. Ideally, most tasks will have estimates of 1 hour. That way, when a 2-hour task requires 2 weeks to complete, you can point to the specific task and its challenges. It provides an easy explanation for why the release was late, why the requirements were too ambitious, etc.

ethnicify 9y ago
This is micromanagement. You're describing micromanagement. Engineers do not need to be managed down to the hour. Good grief.
- padobson 9y ago
  It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less. The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required. Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.
  - 123212321 9y ago
    This sounds like pure misery. No self respecting good developer would work under these conditions.
  - doseofreality 9y ago
    So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long? If this isn't micromanagement, what would you define as micromanagement?
    - beegeezuz 9y ago
      Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.
      - fao_ 9y ago
        Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~
      - chrisbennet 9y ago
        A month is too long to wait. Break it down into smaller units... ;-) I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.
  - drharby 9y ago
    Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it
  - aje403 9y ago
    I would definitely consider a gulag over this
- veidr 9y ago
  In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes. However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive. I feel like I have, over the years, sometimes crossed that line. (And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)
  - deleted 9y ago
    [deleted]
  - Retric 9y ago
    Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless. The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.
    - shagie 9y ago
      An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.” Giving single numbers for an estimate with uncertainty is bad for all parties. Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.
      - Retric 9y ago
        That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%. AKA Y is much higher when you deal with low hour estimates. This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.
- janlaureys 9y ago
  This gives me PTSD to a consulting job I had as a web developer where every 15-30 minutes the project manager would come up to my desk to ask what I've been up to and what I had achieved (in the last 15 minutes). He'd also get upset when the feature I was working on wasn't finished yet since the last meeting.
  - matte_black 9y ago
    With an interruption every 15 minutes, sounds like you would never reach a state of flow.
    - ImSkeptical 9y ago
      My own strategy with such people is to bore them into never speaking with me. Every such question, I'll take a moment to compose my thoughts, and then begin explaining, as thoroughly as possible, in a monotonous cadence, exactly what's been going on. I'm also sure to always add that reporting on progress is consuming a significant amount of time, especially because it is an interruption. I also repeat any instruction given to me in different words, and describe what I'm currently working on, what I think the priority of the new thing should be relative to current tasks, and ask if they agree with me. In my experience, people simply lack the will to repeatedly endure lengthy and dull interactions. I can tell they zone out soon after I start talking, and I keep lashing them with boredom until they learn to not interrupt me. I'd suspect the kind of person who asks for an update every fifteen minutes is doing so out of a minor sadistic impulse, rather than for any legitimate reason. If so, the important thing would be never to appear bothered by it. That would be my strategy at least.
  - EKLM-ZK88 9y ago
    I've personally witnessed the VP of product stand over our senior engineer's shoulder while he tried to debug some serious bug that we couldn't reproduce in dev/stage for hours until it was done. That same engineer also had the CEO stand over his shoulder and actually ask "You don't mind if I stand here and watch do you?" The same CEO constantly brags about his "10 years of experience building companies with successful exits"(10 years of experience vs 1 year of experience ten times), and calls his company the "Amazon of the south". Reading this article gave me flashbacks, but it does help to know that it wasn't just that company.
- ajb257 9y ago
  It's not micromanagement. It's planning. There's nothing wrong with those tasks having no-user facing changes, or giving all the tasks to acheive a higher-level goal to one developer. However, going in and making those tasks forces you to think over the problem properly and come up with a game plan. If you don't know a given approach will work, sometimes that's best to timebox some experimentation time (say an afternoon), but then you can also say to your PM/EM 'ok, we need a little time to work out how long it's going to take', and decisions can be made accordingly as to priorities. Very little of being a software engineer is about writing code. That's just typing. The skill is being able to come up with a coherant plan to solve a problem. That's why architects don't tend to write a lot of code.
maxxxxx 9y ago
This works only if you do things that are well understood beforehand. If you are doing things that require a lot of research and experimentation this project plan falls apart quickly.
- mateo411 9y ago
  Correct. If you have to do research and experimentation before you can make good estimates, then you need to allocate time to do that. I use the term discovery phase to describe this. You give the discovery phase a certain amount of time to complete, it should be from a few days to 2 weeks. The deliverable at the end of discovery phase is a document. The document explains what experiments were run and what we should do next.
  - maxxxxx 9y ago
    This still rubs me the wrong way. I guess I personally don't like micromanaged environments. I don't want to have to explain every little step and report back all the time to people whose only interest is the deadline. I prefer to be treated like an adult who can be trusted to do the right thing to get to the goal quickly without being supervised at every step. But I know plenty of people who need constant monitoring and handholding.
    - atridan 9y ago
      I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task. This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.
      - maxxxxx 9y ago
blauditore 9y ago
I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time. My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).
- hrktb 9y ago
  > If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. This seems to be a concept so hard to grasp for non technical managers. By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions. Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.
andyjohnson0 9y ago
> My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small. The problem with this is that the time required to complete all the pieces is almost never equal to the sum of their estimated durations.
zintinio5 9y ago
I would quit this team.
expertentipp 9y ago
My current team is estimating up the to one hour and afterwards reporting the work with an hour resolution. It's low cost center squeezing the last cent form the engineering workforce. We are not asked for opinion or for a decision but to implement the tasks distributed by architects and Scrum masters. I'm quitting this place with the first opportunity possible and before taking all holidays until the end of the notice period. I will not even say goodbye.
- s73v3r_ 9y ago
  "taking all holidays until the end of the notice period" Do you mean bank holidays? Cause regardless of how you feel about your company, you should always take those. Rest and disconnect from work are important, especially in environments where you really like the work or the job, and the risk of overheating is much greater.
  - vanilla_nut 9y ago
    Presumably he means taking his vacation days so he doesn't have to put in any days of work in the 2 weeks after he puts in his notice. I'd guess he isn't American -- the term "holiday" is interchangeable with "vacation" in most of Europe, for instance. That being said, your point about bank holidays is a good one. Never give your company free labor -- they'll never give you free capital.
    - EKLM-ZK88 9y ago
      I would be careful with this, my last employer refused to pay for unspent vacation days, and if you put in your notice or thought the individual was likely to quit they wouldnt approve your PTO requests. I don't know if this is legal (South Florida), but all the information i find online for this state say that the employer is not required to pay out your time (varies by state).
  - expertentipp 9y ago
    I mean withdrawing entire remaining annual leave to spend in the office the minimal time possible during the notice period.
laythea 9y ago
1 hour tasks! Sound like a recent working environment I was in where I witnessed a poor permanent employee driven to booking 10 mins to a task by this mentality from management down. Also, none of them spoke to each other due to the time-micromanagement. No thanks.
AFNobody 9y ago
I think you are overdoing it simply because per-hour estimates are extremely time consuming to produce and borders on micromanagement. Realistically, tasks should be grouped into roughly day-sized estimates for any long project with an equally large QA pool possibly run in parallel. Granularity only gets you so far before the returns diminish to the point of worthlessness. Imho anyway.

scottinseattle 9y ago

Are you sure it's impossible to get time estimates right for building software? What do you even mean by that? What methods have you tried and in what context(s)? How much data substantiates your claim? I'm not trying to be a dick, but there's a lot of shit that passes for wisdom online which boils down to, "I tried it once and it didn't work for me." Most software engineers I've spoken to, when challenged, admit they don't know shit about software estimation techniques and haven't even heard of PERT, Wideband Delphi, work breakdown structures, etc, etc. At least read the book Software Estimation: Demystifying the Black Art before you go around saying that it's impossible to get time estimates right for building software. I think if you did, you would be a lot less cavalier about it.