The Mythical Man Day — Another Fallacy of Software Development
As you've read in a recent blog post I focused on Brooks' Law. It is one of those ugly truths of software development that we never seem to learn to escape. This led me to thinking about a follow-up to the law and book, that of the Mythical Man Day.
We have all experienced this one as well.
Well intentioned software development managers or project managers ask you how long it will take you to perform some bit of work. You'll typically give them an estimate in units of days or weeks. They might challenge you a bit on your estimates and you might give in—in one direction or the other. Eventually, you'll come to a loose agreement on the appropriate level of effort, again, in agreed units.
Once this happens, they will transfer the estimate to some sort of scheduling tool.; your estimate and all the others they have received. Depending on the type of project, they might very well apply some sort of buffer or padding factor to your estimate, but that's a story (or blog post) for another day.
Don't worry, we're working our way up to the dirty little secret…
They rarely assume that developers work 8 hours in a day. The truth is that depending on the organizations methods, the skill of the developer, the groups' dynamics and the type of tasks, the answer is that it always DEPENDS as to how much time each developer can actually contribute over the course of a day.
I've worked with many project managers that wisely have a conversion factor when translating estimates to schedules. The vast majority use something like 75 – 80% as a productivity factor. Another rule of thumb often thrown about is the 6 hour per day rule—again 75%. They'll use this "conversion factor" when scheduling the estimate time – so a 4 (8 hour) day work estimate would take 5 calendar working days (40 hours) to complete.
The factor is intended to compensate for normal interruptions, meeting time and other "down time" that all developers encounter. However, the problem isn't converting the estimate, its using a common factor across the entire team and using a non-realistic factor which isn't based on factual metrics, that leads to problems.
I'll give you another view. 6th Sense Analytics is a typical start-up environment. Very bright and energetic engineers are excited about working on a new, dynamic product. They're creating something neat and having fun doing it. There is also very little process overhead, as the team is small and there isn't the time nor need for it. From a pure software productivity perspective, it doesn't get any better than this!
Guess what the average Active Time is within the 6SA development team? Approximately 20 hours per week or perhaps less than 50% of the overall time worked. Keep in mind that this is a startup, so serious hours are being put in. At some peak focus times, Active Time can approach 40 hours per week, but only for 2-3 week intervals. Then the team needs to relax back to their normal pace.
This is the myth of the Mythical Man Day—that we are able to produce tangible development work (artifacts – code, documents, tests, etc.) between 75% to 100% of the time in our teams.
I'll complete the secret in my next post, so please wait just a little bit longer…
Previous Post:
Brooks’ Law Continued — Ramp-up Step Function
Next Post:
Mythical Man Day — The Fallacy Continued
