Talking Tech - The Mythical Man-Hour
Work in any industry is often broken down to man-hours, the expected amount of work that an average person can finish in an uninterrupted hour. While that’s great for planning and budgeting purposes, I think it’s a terrible measure that gives inaccurate estimates at best and coerces people to work absurd amounts of unpaid hours at worst. And much like Fred Brooks probably suggested in 1975 (I’ve never actually read the book that I based this title on), there are several reasons why basing expectations on the work capability of some theoretical person in some theoretical hour is unhelpful and often harmful.
The first problem with man-hour estimates is the amount of work. Who is this average based on? In the software engineering industry, there are vast differences in experience, specification, and familiarity with different products. If you ask me to build something in a language I’ve never written for an industry that I have no exposure to, it’s going to take a while. A recent code school graduate with experience in that platform and familiarity with the business, they could likely finish well before me. These nuances and differences suggest that an “average” developer doesn’t exist. Where do you get the average from, then?
Beyond the complication of an average hour’s work, the idea of uninterrupted work hours is a joke. Anyone who expects employees to be fully engaged for an entire shift may as well just go ahead and check themselves into a mental institution. Figures that I have heard thrown around tend to center around roughly 60% actively engaged hours out of a shift as a good target. Anything more and you’re burning out employees faster than you can hire them. Anything less and your employees aren’t as effective as they could be.
Some organizations take that ~60% figure and set hours of work based on that. Out of an 8 hour shift, something like 5 hours are considered dedicated to project work. The rest is allocated for meetings, communication, or whatever else employees are tasked with doing. This is a step in the right direction, but it still sets an ideal that is unlikely. Any time I get interrupted with some task to investigate something, I have to set aside what I’m working on, figure out the details of whatever urgent matter has come up, and pursue the issue. That doesn’t happen every day, but it does happen frequently enough not to be ignored in these hours calculations.
We already have some shaky footing with average work and uninterrupted hours, but let’s take it a step further. Most software development teams have multiple members that often share work on a given feature. This distribution of work complicates estimates yet more. We all have to spend time investigating new features as they are requested, often transferring knowledge about existing code and how to properly integrate with it. If three developers spend an hour researching a feature, that’s three hours. Furthermore, there is a continued effort to ensure that we don’t accidentally duplicate code or negatively interact with code that someone else is working on. There is an inherent cost to throwing multiple developers at the same problem.
Let’s say that you have a firm grasp on average work, guaranteed hours, and one developer per feature. You still aren’t out of the woods on this man-hour situation. The business and its representatives are going to throw their share of wrenches in the gears as well. Priorities shift frequently enough that you’re going to spend some time bouncing between projects or at least meeting with representatives to confirm that the current project is the highest priority. And even if priorities don’t change much or at all, any project or feature is going to have unknowns that you can’t accurately estimate for. Any new technologies that have not yet been used in a project are going to take time to investigate. Technical debt builds up and breaks something critical at the worst time. A perfectly orchestrated team will still encounter man-hour woes simply by the nature of the business.
Up until now, these have all been genuine concerns that even the best-intended organizations are going to encounter. Things get even worse with a toxic organization that wants to squeeze their developers for every ounce of productivity. We can ignore the costs of churn and turnover and still find that overwork is expensive and detrimental to timelines. Primarily, a vicious cycle of sandbagging is a huge problem in some organizations.
Say a dev team successfully completes a feature, but went slightly past the scheduled completion date. For the next feature, they take initial estimates and increase them by some small amount to account for those unexpected issues. Eventually, the business begins to realize that developers are sandbagging estimates to buy a little breathing room and decides to cut those final estimates by some percent to combat the bloat. This aggression against developer estimates forces the team to choose between falling behind schedule again or working unpaid extra hours to finish the project within the timeline. In either case, it absolutely crushes morale and incentivizes developers to sandbag worse or simply ignore timelines.
Underscoring all the previous points, adding more developers to a project that is behind schedule will usually delay it further. Onboarding new developers to a project takes time from the developers already working on it. Furthermore, these additional hands in the proverbial cookie jar exponentially increase the likelihood that code will be accidentally duplicated or improperly integrated. Hence, these additional resources actually push timelines even further out, directly counter to the goal of catching up.
So far, we have determined that man-hours are usually inaccurate and often worthless. Even if they did have some value, the cost to track them may not be worth the benefit. Requiring that your developers record exactly how many hours they spent on any given task is in itself another task. This logically allows less time for productive work and thus less work completed over time. Most developers hate logging hours anyway, but it quantifiably reduces the amount of work they are able to complete in the best of scenarios.
In some cases, such as contract work, tracking hours is necessary. Billing is based on hours, and there isn’t much that can be done to help that besides automatic tracking (another idea that I hate). However, for traditional software companies and internal development teams, tracking hours is almost never a good idea. I understand the desire to have an accurate timeline, but if your timeline can be significantly impacted by a few hours here or there, you need to take a step back and approach with a much more general scope. Story points, sprints, and other longer time frames allow the flexibility for developers to complete their work the way they see fit, but also gives the business some indication of when a feature might be done.
By working together with the business instead of against, dev teams can generate quality work in a timeline that is specific enough for forecasts without getting down to specific hours. This means forgetting about man-hours and using better tracking that helps everyone involved.
The first problem with man-hour estimates is the amount of work. Who is this average based on? In the software engineering industry, there are vast differences in experience, specification, and familiarity with different products. If you ask me to build something in a language I’ve never written for an industry that I have no exposure to, it’s going to take a while. A recent code school graduate with experience in that platform and familiarity with the business, they could likely finish well before me. These nuances and differences suggest that an “average” developer doesn’t exist. Where do you get the average from, then?
Beyond the complication of an average hour’s work, the idea of uninterrupted work hours is a joke. Anyone who expects employees to be fully engaged for an entire shift may as well just go ahead and check themselves into a mental institution. Figures that I have heard thrown around tend to center around roughly 60% actively engaged hours out of a shift as a good target. Anything more and you’re burning out employees faster than you can hire them. Anything less and your employees aren’t as effective as they could be.
Some organizations take that ~60% figure and set hours of work based on that. Out of an 8 hour shift, something like 5 hours are considered dedicated to project work. The rest is allocated for meetings, communication, or whatever else employees are tasked with doing. This is a step in the right direction, but it still sets an ideal that is unlikely. Any time I get interrupted with some task to investigate something, I have to set aside what I’m working on, figure out the details of whatever urgent matter has come up, and pursue the issue. That doesn’t happen every day, but it does happen frequently enough not to be ignored in these hours calculations.
We already have some shaky footing with average work and uninterrupted hours, but let’s take it a step further. Most software development teams have multiple members that often share work on a given feature. This distribution of work complicates estimates yet more. We all have to spend time investigating new features as they are requested, often transferring knowledge about existing code and how to properly integrate with it. If three developers spend an hour researching a feature, that’s three hours. Furthermore, there is a continued effort to ensure that we don’t accidentally duplicate code or negatively interact with code that someone else is working on. There is an inherent cost to throwing multiple developers at the same problem.
Let’s say that you have a firm grasp on average work, guaranteed hours, and one developer per feature. You still aren’t out of the woods on this man-hour situation. The business and its representatives are going to throw their share of wrenches in the gears as well. Priorities shift frequently enough that you’re going to spend some time bouncing between projects or at least meeting with representatives to confirm that the current project is the highest priority. And even if priorities don’t change much or at all, any project or feature is going to have unknowns that you can’t accurately estimate for. Any new technologies that have not yet been used in a project are going to take time to investigate. Technical debt builds up and breaks something critical at the worst time. A perfectly orchestrated team will still encounter man-hour woes simply by the nature of the business.
Up until now, these have all been genuine concerns that even the best-intended organizations are going to encounter. Things get even worse with a toxic organization that wants to squeeze their developers for every ounce of productivity. We can ignore the costs of churn and turnover and still find that overwork is expensive and detrimental to timelines. Primarily, a vicious cycle of sandbagging is a huge problem in some organizations.
Say a dev team successfully completes a feature, but went slightly past the scheduled completion date. For the next feature, they take initial estimates and increase them by some small amount to account for those unexpected issues. Eventually, the business begins to realize that developers are sandbagging estimates to buy a little breathing room and decides to cut those final estimates by some percent to combat the bloat. This aggression against developer estimates forces the team to choose between falling behind schedule again or working unpaid extra hours to finish the project within the timeline. In either case, it absolutely crushes morale and incentivizes developers to sandbag worse or simply ignore timelines.
Underscoring all the previous points, adding more developers to a project that is behind schedule will usually delay it further. Onboarding new developers to a project takes time from the developers already working on it. Furthermore, these additional hands in the proverbial cookie jar exponentially increase the likelihood that code will be accidentally duplicated or improperly integrated. Hence, these additional resources actually push timelines even further out, directly counter to the goal of catching up.
So far, we have determined that man-hours are usually inaccurate and often worthless. Even if they did have some value, the cost to track them may not be worth the benefit. Requiring that your developers record exactly how many hours they spent on any given task is in itself another task. This logically allows less time for productive work and thus less work completed over time. Most developers hate logging hours anyway, but it quantifiably reduces the amount of work they are able to complete in the best of scenarios.
In some cases, such as contract work, tracking hours is necessary. Billing is based on hours, and there isn’t much that can be done to help that besides automatic tracking (another idea that I hate). However, for traditional software companies and internal development teams, tracking hours is almost never a good idea. I understand the desire to have an accurate timeline, but if your timeline can be significantly impacted by a few hours here or there, you need to take a step back and approach with a much more general scope. Story points, sprints, and other longer time frames allow the flexibility for developers to complete their work the way they see fit, but also gives the business some indication of when a feature might be done.
By working together with the business instead of against, dev teams can generate quality work in a timeline that is specific enough for forecasts without getting down to specific hours. This means forgetting about man-hours and using better tracking that helps everyone involved.
Comments
Post a Comment