A team of crack developers does not a successful project make

Developers hate schedules. That conclusion is pretty easy to derive. I was thinking of 3D Realms's long-awaited Duke Nukem Forever, that Wired magazine has so appropriately honored with a Lifetime Achievement Award in the Vaporware/Phantom Software category. Now I don't know anything about said company and said product's development team, but saying "I doubt they have much of a schedule" is just stating the obvious. Sadly this isn't the only instance of its kind in the software industry. I believe a vast majority of projects have either no schedule (and hence no deadline) or have no adherence to schedule. No wonder these projects move slower than molasses dripping out of a fur-lined syrup pitcher.

But why do developers hate schedules? Too often they are expected to follow schedules imposed from the top. That is a recipe for failure right there. Then there are those programmers that are involved in scheduling, who often tend to estimate on the lower side. There are many reasons for this:

• The "Oh, I do not want to come across as a slouch" mindset


• Developers feeling they can use this opportunity to prove their hard work and dedication


• Ignoring the fact that the estimate must include more than just the time it takes to write the code


• Not recognizing that testing and debugging take more time than does coding


• Ignoring the difference between calendar day and work day


• Relying on gut feeling more than actual estimation techniques. This is the infamous throwing-numbers-out-of-your-ass technique


• Pressure from management to give 110%, whatever that means!

I believe that the failure to implement a sound, well-planned schedule is the reason many projects have open ended release dates. A lot of us are under the illusion that a schedule is a sacrosanct document that does not evolve. Nothing could be farther from the truth. In real life, the schedule must evolve and accept change just as any other part of the development lifecycle does.

A good schedule incorporates numbers provided by the developers who will actually write the code. It accounts for time overruns by creating buffers for existing features and for things that will inevitably crop up during the execution of the project. I mean, have you ever worked on a project where the requirements haven't changed or where new features weren't added when the design was already solidified? So when preparing the schedule, why pretend like that's not going to happen this time? A line item for that will save you tons of heartache later.

Estimate time required for testing and integration separately from the time to "develop" features. And don't forget that old faithfuls -- documentation and debugging -- either. The schedule must also account for holidays and vacation time for each team member. And while you're at it, add a few days to account for fire drills, sick days and snow-outs | storms | blizzards | hurricanes | Seinfeld marathons on TV.

Good schedules list features and their owners. This very critical. This also assumes that you have completed an iteration or two of identifying what those features will be. You must have a system where people own features. One cannot overstate the importance of the sense of responsibility this inculcates. It also eases bug/RFE assignments and ensures the minimal turnaround time for bug-fixes (because the person who develops the feature fixes its bugs fastest). Also be considerate and don't expect your developers to do more than one thing at a time. A person assigned too many parallel tasks may not be as productive as someone who focusses on one task at a time. You will have one or two people on the team that are fully capable of handling multiple tasks. Good, make sure they get a raise and feel appreciated. But believe me, not every developer has the bilateral proficiency of Leonardo da Vinci.

If you are in charge of creating the schedule and if you choose to embellish the estimates, please bump them up, not down. And if you think you need to cut, then cut features, not the time it takes to develop features.

I do not mean for this to be a flame bait but the Duke Nukem tardiness syndrome is very common in open source projects. My take on it is that most of the projects are run by developers (good ones I might add) and have little or no management oversight. Hence, deadlines are alien concepts and surely crack coders can't be bothered by them.

It is foolish to develop projects with arbitrary time-based deadlines (for instance, deciding you will deliver by March 2006 before you have even understood the requirements and the scope) but it is simply unforgivable to embark without a plan or a schedule. Write a schedule that works best for you. And stick to it.

Email this | Bookmark this