Each month, I decided I would dedicate myself to improving one simple area of my professional life. This month I have chosen (drum roll please): software scheduling and estimating. I really suck at it and I need to improve.
As a software developer, I hate schedules. Making them are a pain, and most of the ones I have seen are pretty much worthless.
When I was a contractor at fortune 500 company (I won’t name it), scheduling was especially ridiculous. It was at that contract that I learned how not to manage a software project.
I swear, all of this actually happened:
- When there was a risk of schedule slippage, the manager would have “one-on-one” meetings (that would last 30 minutes or more) with each of the programmers individually. More specifically, these “one-on-one” meetings were also attended by the technical lead which essentially made them a threesome. The lead would produce a list of tasks and slide it across the table for you to look at, while the manager would ask for each task, “when is this going to be done?” The team lead would glare at you and then write down your answer. If you asked which one needs to be done first, he would reply, “they are all important. They all need to be done.”
- When “crunch time” came, the manager would nervously demand twice a day “one-on-one” (threesome) meetings. EVERY DAY. Thankfully this stopped after the 3rd release.
- To maintain a sense of urgency the manager hid the real release date, and made up a fake release dates. His logic was that even if they slipped he could still make the “real” release date. Unfortunately, this constant stream of unattainable fake milestones and failure sucked the enthusiasm from the permanent employees.
The department employed a ticket/bug tracking software that had the ominous feature of producing evil .csv files. These .csv files could be imported into an excel spreadsheet where sanity was replaced with charts. Number of closed issues was something measurable, so it became the yardstick everyone was measured against. This caused some very predictable problems:
- By itself this wouldn’t be bad except that the task, “debug and patch the Hot-plug PCI kernel driver (and back port to the 2.4 kernel)” was measured the same as “misspelled the word disk drive on dialog 3″. One task took 3 weeks, while the other took a total of 10 minutes. The developer who debugged and patched the kernel driver was (in the eyes of the management) 1/1000th as productive as the developer who wrote buggy code.
- More importantly, the most productive code was seen by the other developers as the most adept at creating bugs. Of course, they would be honor bound to report the bug and fix it. On task may result in to other bugs. A developer who was diligent in testing their code before checking it in would get credit for one fix. A developer who broke the build and fixed it would get credit for 2. If their bug fix didn’t work and another. Worse, testers were unaware what bugs had been entered, so one bug would be reported multiple times.
- Developers argued and negotiated with testers to keep unfixed bugs under the table (or press them to enter them as new issues and not reopen existing ones).
- Developers also would monitor the new bugs and immediately claim the easy ones.
- Next, the group was reorganized. After two project managers were added, the ratio of developer to manager grew to one manager for every two developers.
- To coincide with the new project managers, the capabilities of the bug tracking software were “improved,” offering even more information for spreadsheets. Not only was each task afforded a due date, but suddenly each task had a scheduled due date (the date that the developer committed to closing the ticket), and last updated date (the last date that the developer modified the ticket). Developers had to respond to new tasked that were assigned to them within short period of time. If they scheduled the due date past the project manager’s due date, they had to explain why. Also, each week a spreadsheet presented all of the outstanding tasks where each developer was publically grilled by three project managers in turns. How cool is that?
I really didn’t shed any tears when during the second wave of layoffs; I was one of the consultants walked out the door. I took a week off and within another week I was on a new contract with a significant raise.
So now I have dealt with the trauma of being whipped by Excel wielding project managers, how can I improve my estimating to make dealing with clients more of a science rather than a guessing game?
I’ve decided to utilize the simplest methodology for generating realistic software schedules, namely that espoused by Joel Spolsky. The methodology is relatively simple:
- Use Microsoft Excel. More specifically, don’t use Microsoft Project.
- Keep it simple.
- Each feature should consist of several tasks.
- Only the programmer who is going to write the code can schedule it.
- Pick very fine grained tasks. They should be measured in hours, not days.
- Keep track of the original and current estimate. Joel estimates that programmers can become very good schedulers with about one year of experience.
- Update the elapsed column every day.
- Put in line items for Vacations, Holidays, etc. (for long schedules). Should be a feature for Vacations and such.
- Put debugging time into the schedule.
- Put integration time into the schedule.
- Put buffer into the schedule.
- Never, ever let managers tell programmers to reduce an estimate.
- A schedule is like wood blocks. (get a bigger box or remove some of the blocks).