This is a follow up to On Our Project, We’re Always 90% Done.
The coder is the one on the hook for long nights, weekends, and stress-related health problems if the estimates suck. It’s in your interest to exert as much control over estimation and scheduling as you can. If you’re not making the estimate, someone is making it for you.
If you think about it, you’re opting out of an ongoing salary negotiation process. You’re going to work more for the same amount of money, and worse yet, you’re going to have to squeeze that work into the same amount of time, under stressful conditions. Why would you do that?
McConnell’s “Software Estimation” book addresses this problem of wildly inaccurate early estimates quite well. I highly recommend it. In a nutshell, estimates need to carry error bars, so early estimates would be given but with a disclaimer of +/- 100% (or more!), and later estimates get closer to being correct.
You will have to manage expectations, though. Human nature leads to the shortest end of the date range becoming the remembered end date, the guess being remembered as a promise, and the latest feature set being remembered as if it were the original feature set.
This is a big reason to hire a good project manager: they’re there to facilitate the change control process, or planning game, or whatever you call it in your organization when the paying folks want more stuff, and the PM reminds them that need to pay more and wait longer in order to get more out of the dev team. A good project manager can make a huge difference to the stress level and likelihood of success of a project.
It’s psychologically icky for developers to have to participate in the estimation and scheduling process — “eww, it’s a non deterministic domain with lots of ill-defined inputs!” — and I’ve seen some managers play head games like “Oh, you need more time? I thought you were really good at programming… I guess not…” to try and manipulate developers into working nights and weekends out of a sense of guilt or wounded pride. But you need to suck it up and keep providing status updates and reminding people how the process works, because you-the-programmer are the expert on the nature of programming.
Yes, it’s more like Lewis and Clark or the Apollo project than like building a house, and there are just going to be a lot of surprises, but you can still provide a framework and exert a tremendous amount of control over how the team will operate. Things like whether you plan to build a technology proof-of-concept to make sure your architecture doesn’t suck, or whether you intend to spend lots of time writing automated tests and doing daily code reviews in order to control that horrible “bug fixing” phase toward the end are in your hands if you participate in the estimation process. You’re being offered an opportunity to make sure that all those important tasks like performance testing and cross-browser testing and writing an installation guide and an operations manual for the sysadmin get done. It doesn’t matter if the estimates for those tasks are completely wrong at first – what matters is that they’re on the list.
And really, the largest battle you’ll probably have to fight is the one over scope creep: we can’t launch until it has all the original features plus all these additional changes and new features perfectly working, but we need to launch tomorrow. That’s also human nature, and you need to train people to release early and often. Agile methodologies can help here, if you can get your software working and stable from a very early point in the project, and keep it that way. Then you probably have a launchable product very early, and you can just push highly-desired features into post-1.0 releases.
In any case, a list with a bunch of crappy numbers and low confidence factors is a lot better than no list, or a one-item list with a crappy number and an implied 100% confidence factor.