Anybody with a few years of experience has had the displeasure of being held to overly optimistic development schedules. Sometimes it's endemic to the organization, possibly as a result of having to submit ridiculously low bids in order to secure any work whatsoever. Sometimes it's the result of a simple brainfart. Sometimes it's the result of having giant alien space ants in your organizational chart that callously give out unreasonable demands to their human underlings. (I, for one, welcome our new insect overlords. I'd like to remind them that as a trusted code monkey, I can be helpful in rounding up others to...toil in their underground sugar caves.)
This post won't contain anything new to all of you awesome code gorillas with 15 years of experience. Consider it a rant. Remember, this is the blog of a journeyman code monkey, not a super-duper guru code monkey. I aspire to reach your exalted plane of existence where we can have these great conversations I made up in my mind:
- "Ho, ho, yet another little code monkey just saw The Mythical Man-Month for the first time."
- "How quaint. I can't wait until he goes through his 'Lisp is the most beautiful language EVAR' phase." *flings code gorilla poo* "Let's go back to writing mind-bogglingly expressive, functional, concurrent, mind-reading languages in our spare time."
- "Superlative idea, old chap!" *flings code gorilla poo*
- "I love Emacs!"*flings code gorilla poo*
Vacation/leave
Assuming 2 weeks of vacation and 2 weeks of sick leave per year, you can count on 4 weeks per year, on average, that each developer will be out of the office. Throw in another 10 days of various holiday leave, and 6 out of 52 weeks of the year are gone. Poof! Write them off now. That's 11.5% that the project is not going to get back.
Management can always disallow vacations when the project starts falling behind, calling developers in on sick days, working holidays and weekends, etc. However, if schedule-affecting factors are habitually ignored, these measures quickly become a permanent state of affairs, a perpetual death march, mass hysteria, dogs and cats living together! The end result of this is our next item...
Developer turnover
It's a fact of life. Developers are going to leave, and management will need to hire new ones. Face it, 20% of your people are going to be recycled within the next year. Some years more, some years less, but that's going to be your long term average. If it's significantly more, maybe you work for Electronic Arts, if it's much less, you must work for Google, that fabled realm of free gourmet lunches, super geniuses with complete intellectual freedom, and disgustingly amazing stock benefit options, or some other fairyland that a real programmer wouldn't be caught dead working for, and you should leave a comment telling me who I should send my resume to.
Losing strong developers has a huge impact on project schedule that I'm not sure how to quantify just yet. But it's there, and it's significant.
Nasty surprises
So I'm working out in the yard, digging up some roots,trying to make up for ineptitude by putting on displays of brute strength, without much success, (or much brute strength for that matter), and I've encountered this root with a bad personality. I'm hacking at this thing, pulling it up, and it goes on and on. It's hard work, but I seem to be making some progress when my wife comes out to tell me what an amazing hunk of a man I am. I know it's coming - she's got that look of awe and wonder in her eyes. As I hold up the trophy root, she sings my praises - "Honey, why are you destroying the sprinkler system?"
Oh. I thought roots were supposed to be black and rubbery.
Well, looks like the whole weekend is shot to crap. Now I have to make 20 trips to Home Depot, trying to figure out what piece I'm supposed to buy while my handy neighbor wonders how this hopeless wreck ever managed to live past the age of seven.
This happens in software, not always, but often. Attempts to extensively plan your design to account for every single possible eventuality will rapidly demonstrate diminishing returns, to the point where all that time spent planning kills your productivity, and you would have been better off spending some of that time on rapid prototyping and other forms of actual development. (The extreme opposite of over planning is "Agile Programming", which comes with its own problems)
Surprises will affect your schedule in bad ways. The good news is that you can attempt to account for this by collecting data on your past estimates, being disciplined and consistent in your estimating methodologies, collecting data on time spent on unplanned surprises, and figuring out an average percentage of buffer time you need to build in to your future estimates.
Distraction
As you come up with more refined plans, and dutifully track your work time, you'll notice that a lot of your time is spent on things not in your original plan. Some of this is in the form of unplanned development surprises, as covered above. Some if it is in other tasks, checking email, workplace training, meetings, answering the phone, random conversations, office chair demolition derbys, you get the idea. The end result is that, as an industry standard, developers, on average, spend only 15 hours out of a 40 hour work week toiling on tasks that were planned beforehand.
This means that if you've got a task that you've planned out at 80 hours of effort, even after adjusting your effort estimate to correct for your own built-in estimating inaccuracies, there's no way that sucker is going to be done in two weeks of normal 8 hour days. On average, you're gonna need 5-6 weeks to get that done.
This is list is by no means comprehensive. But accounting for these factors gives you a start at making more realistic estimates than I did, all bright-eyed and bushy-tailed, straight out of college.
