This reads like a gentle, and informative, version of my own answer: avoid giving time estimates if at all possible. One way to do it is through a sidestep like you've provided, which involves some initial prototyping and requirements "bargaining", and coding on the side when they aren't looking to "sneak" in some work before the estimate (thus making a substantial part of your "estimate" an actual real-world measurement of the work you've already done). Another, better (in my opinion) but far less likely, approach is to actually finagle your client/boss/whatever into adjusting to suit a business model that isn't dependent upon time estimates.
I'm not advocating something like eXtreme Programming or Scrum Agile Development. I'm talking about telling the employer "I'll provide you with a working prototype. If you like it, I'll work up something that is actually usable for what you need, and you'll pay me for the work so far. If you like that enough, I'll start working on feature requests and get paid for them as I finish them. If not, you can get someone else to add features, since you'll already have working software that can be extended. We're all happy, since I've gotten paid for what I did and you'll get the development you want, one way or another, without substantial wasted time or cash. Nobody gets ripped off."
While this can be adapted to salaried employment and/or product-for-sale development, in at least some cases, it is obviously best suited for internal tool development, web development, and so on, by outside consultants. It draws somewhat on the ideas expressed in the Agile Manifesto without falling into the trap of rearranging deadlines and making your death-marches and schedule overruns different rather than nonexistent. I've noticed that most of the formalized agile methodologies seem to turn death-marches into death-races while making it appear at first blush that they solve the death-foo problem altogether, which seems almost as suboptimal as just going all the way back to waterfall development.
Independent Internet startups (when they're done "right") seem to have the right idea, much of the time: eliminate formalized scheduling altogether, and just do things as quickly as possible without sabotaging the project. This forces prioritizing more effectively (get the most important stuff done first, the other stuff when you have time) and tends to eliminate the real hazards of over-schedule, over-budget development (a common result of having predetermined project-completion standards with project schedule estimates). This tends to work best for independent Internet startups because they get to do things however the hell they want to. Next best, for consultants who have the luxury of choosing their clients intelligently and have the social acumen to talk clients into it, because they get paid for the work accomplished rather than the time spent working. Third, for salaried employees who are working on internal tools or web development projects. It tends to work least well for people like Microsoft employees, because death-march development is almost indivisible from market dominating shrinkwrapped retail application development.
I left a category of development out of that explanation that bears special attention: noncommercial open source projects. The reason I left it out is that there's exactly zero perceived necessity of offering schedule estimates. The reason it bears special consideration is that open source development so naturally uses development technique similar to what I described, with each developer working on the features that are most important to him or her, with each project founder creating a barely-working prototype that gets augmented as opportunity arises because (s)he wants to start using it as soon as possible, that it serves as an excellent model for how to attempt to organize your development methodology in general. The only exceptions are that A) there's barely any motivation to work quickly at all after the first working prototype is developed, though development still often happens quickly, and B) development tends to end up far more distributed and less traditionally "project" oriented once the feature addition phase of development begins (though in some cases specific feature additions might be projects all their own).
Interestingly, Google's internal development process very nearly mirrors the general open source development community's processes, but with more focus in a sort of insulated world-in-microcosm developer ecology. As commercial software development becomes more service-oriented and less product-oriented in the future (and it definitely seems to be doing so), I think Google's example will probably become the canonical development process prototype for success. Time will tell, of course.
Unfortunately, most developers are still locked into a situation where the only way to get work, get paid, and hold down a job, is through coming up with development schedule estimates that aren't too egregiously off-target (they'll always be off-target, but they needn't always be egregiously so — such estimating is akin to voodoo). There's a lot of good advice in the other responses to the OP; hopefully it will be useful. My own post probably won't be of much use, unless you're in the rare (and lucky) position of being able to avoid schedule estimates altogether by constructing a software development business model that doesn't suck.
When doing web development, I can usually get close to what I describe, but ultimately have to give fuzzy estimates on certain project phases. It's not perfect, but it's better than trying to set a schedule in stone before the requirements are even hashed out (let alone altered later, as they always are). I think in that respect my circumstances are better than most, but not as good as I'd like, when it comes to project scheduling.
|
- apotheon
CopyWrite Chad Perrin |
In reply to Re^2: OT-ish: Estimating time to code
by apotheon
in thread OT-ish: Estimating time to code
by kwaping
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |