Even a chimp can write code

Wednesday, January 26, 2005

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

4 Comments:

  • Good points. After reading this, an editorial in The WashingtonPost by Henry A. Kissinger and George P. Shultz comes to mind. I mean, what if WARS were like IT PROJECTS? Have you noticed that neither one seems to go "on schedule". The release date (exit date) always shifts further out? Maybe we, software guys, can learn something from all this. Here's the article:

    http://www.washingtonpost.com/wp-dyn/articles/A33959-2005Jan24.html
    Results, Not Timetables, Matter in Iraq
    By Henry A. Kissinger and George P. Shultz

    Try to ignore the underlying politics (red state vs blue state stuff) and focus on the difficulty of scheduling aspect.

    Vik
    Fair and Biased [blog.vikdavid.com]

    By Anonymous Anonymous, at January 26, 2005 at 2:19 PM  

  • Very good points. I had to smile, it is all so very painfully familiar. Why oh why would a company schedule deliverable on Christmas or New Years :) Or better yet, sign fixed price 90 day projects prior to gap/requirement gathering stage.

    By Anonymous Anonymous, at January 26, 2005 at 5:15 PM  

  • > and have little or no management oversight

    Most managers have little or no management oversight either. Just because someone has the title "Project Manager" doesn't mean they're good at managing. This is especialy true in IT, where the only requirement for the title is "good communication skills". It's sad that in our field this one skill is a differentiator.

    By Anonymous Anonymous, at August 12, 2005 at 8:00 AM  

  • First, let me mention that often, a schedule is indeed dictated by the head of an organization. And often that party hasn't a clue about the magnitude of the effort. These same people, are often so arrogant that they dictate and with a wave of the hand say "Just hire more temps to get it done when the SCHEDULE REQUIRES".

    Regarding the difficulty in estimating software, I am reminded of a book on Software Design titled "Nailing Jelly to A Tree". Why do you suppose the author came up with such a title...

    Yes, software schedules are often wrong, but software isn't like building a house, with all the required items identified and few if any major unknowns (and hey, guess what, home builders are usually wrong with their estimates also).

    By Anonymous Anonymous, at June 5, 2007 at 6:50 AM  

Post a Comment | Home | Inference: my personal blog