11–20 of 27 posts
When asked for an estimate, one good prerequisite is: "with what confidence level?" Assuming estimating 100 tasks, how many can we safely go beyond the estimate? 20%? 1%? 0.001% Then give the estimate based on some probability curve considering the known unknowns.
Here's my take. Programmers don't underestimate because they're afraid of getting fired or yelled at. In this market, a good developer is unlikely to be fired for honestly estimating. Yelled at, yes. Fired in worse economic circumstances (e.g. 2003)? Possibly. Fired now? Doubtful. Rather, it's about a desire not to be jerked around. Implicit in the demand for an estimate is the threat to jerk the employee around-- either imposing stupid new micromanagement ("Agile") or changing project priorities. No one wants to work for the boss who jerks her around and never lets her finish anything, because soon enough she gets to 3 years and while she's fixed bugs and added a few features, she doesn't have the coherent project that would make the case for promotion or transfer to her target group... because her boss kept jerking her away from projects whenever his hindbrain misfired, he interpreted it as the "this is taking too damn long" impulse, he got impatient, and pulled support. It's a fight-or-flight reaction in the boss when that happens, and managers tend to favor flight because fighters tend to get themselves fired. If you work for a hair trigger "flighter", you can very easily get to 3 or even 10 years without ever actually finishing a project. And flighters love estimates.
A good middle manager isn't one who exacts and reports reliable estimates. A good manager goes out, wines and dines the executives, and gets sufficient credibility for his people that no one ever has to give an estimate.
Anyway, programmers give misleadingly optimistic estimates-- not dishonest, just aggressively optimistic-- because they want to be left alone so they can actually produce something and move along to a better project. This is what "Agile" doesn't get. The thing that motivates us is delivering a major project that gives us enough credibility that we never have to make estimates again; not delivering small cantrips that anyone could do, but in record time. I think that "Agile" provides some structure for junior programmers, but it doesn't provide an exit. Under the Agile Ideology, even the senior programmers in R&D and architectural rules have to structure their work in terms of these dumbass "iterations". Implicit to Agile is the absence of personal progress for an engineer: no matter what you do, you'll always be working on feature-level "user stories" instead of real projects where you call the shots, and you'll always be subordinate to the business.
I've been doing this for almost 10 years and I'm good at it, so what being asked for an estimate communicates to me is that whatever I'm doing isn't really important. I will do what is necessary to meet a real, hard deadline (they're rare, but they exist) such as a bid deadline for a government agency (where people can go to jail for corruption if they grant an exception to someone who's a day late) but the silly deadlines that business usually creates are just resource limits, and (sorry but) I'm too good to work on something so unimportant that I'm not even trusted with a month or few of my own time on it. If you won't accept delivery on my time, then it's not important enough to be doing in the first place, because I will work very hard to make sure it's done reasonably quickly and well, and if you don't trust me on that much, then you should just fire me.
In other words, the difference between "4 weeks" and "2 weeks" is going to mean that I either don't get to do it or have to relegate it to extra hours, then (unless there is a hard deadline, and not some silly target like "Q3 KPIs") it's just not fucking important enough for someone at my level of skill to be doing. So give it to some junior who'll view absolutely anything as a learning experience, and leave me out of it.
When asked for an estimate, one good prerequisite is: "with what confidence level?" Assuming estimating 100 tasks, how many can we safely go beyond the estimate? 20%? 1%? 0.001% Then give the estimate based on some probability curve considering the known unknowns.
[deleted]
When you work with motivated engineers (most programmers are in my experience), they set their own pressure and deliver quality work.
If you have a project supervisor that doesn't understand how quality software is made, leave. Putting in 80-100 hours? Nuts! Your estimates will slip even further when you do that.
"...It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process..." No. You are confusing the natural inclination for people to negotiate with some kind of slippage into "politics" (The word "politics" is most often used to describe "system of people stuff that I do not understand and tha…
I tend to think of politics in the broader sense, and suspect that the author of the piece does as well. It's the process of negotiation between people with different spheres of influence, when a single decision has to be made. Client negotiations are absolutely political.
It is agreeable to be reminded of the fact that psychology influences us and our craft disciplines. We're so occupied with math, algorithms and automation that this may slip our minds. There is a popular psychology book, “Games People Play” by Eric Berne that shows and explains many of those game mechanics. Everybody uses them, not just PMs and bit crunchers.
This book helped me figure out that, in personal relationships especially, I could raise the discussion by one level and talk about the game I was playing in an effort to figure out why and get somewhere useful, emotionally. As in, "I think I'm just playing 'Why Don't You - Yes, But'. I need you to just listen to me while I vent."
Can't recommend enough.
EDIT: I should say that the edition I read seemed a bit sexist? I just ordered the new edition so we'll see if any of that text changed.
This is a nice taxonomy of estimation games, but stopping the games won't address the root problem: Software development is complex enough to be fundamentally unpredictable. The games are just about hedging against people not wanting to hear that.
> Software development is complex enough to be
> fundamentally unpredictable.
The weather is an extremely complex system, yet we use weather forecasts all the time. What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future. ("Maybe I'll carry an umbrella today.")
The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.")
Forecasting the completion date of a software project is no more complex[1] than predicting the weather or the future price of an equity. In no way is it "fundamentally unpredictable." What's different is that people don't regard project estimates as, well, _estimates_.
[1] It's probably a lot simpler.
I'd say that developers do pretty clearly prefer working in an environment where they aren't required to provide estimates and meet arbitrary deadlines (nobody likes hard deadlines either, but there's a difference between a window to launch a rocket to study halley's comet and a manager who figured that saying "march" rather than "may" might get the team to work a little harder).
This does't mean that developers don't like to work hard or produce good work, I think they just greatly prefer to take on a task, work diligently at it, and show progress rather than be pressed for estimates based on limited knowledge that quickly morph into hard deadlines before the problem is adequately understood.
Yeah, I'm stating the obvious. But thing is, it isn't a complete pipe dream. I do know developers who have quite a bit of autonomy. While the do have to answer for what they've been up to, they develop software and show the value of that software. They don't take specs, give estimates which become deadlines, and get reviewed based on how well they met those deadlines.
It's all about aspirations. I have a few for myself. I'd like to get to the point in my career where my interview focuses more on my existing work and contributions (github, blogs, speaking at conferences) rather than my performance on finding cycles in linked lists at the whiteboard. I'd like to work in a quiet office (happily shared) with a door that closes rather than a loud, open office with back visibility. And yeah, now I can add in that I'd like an environment where I can work steadily on a challenging problem and be evaluated by what I have accomplished.
Just to be clear, nobody owes me a job on my terms, I have to earn it. But, ahem, the loudest people in our industry seem to be the ones who think the world owes them a talented developer on their terms. If you're having trouble attracting and/or retaining talent, you might want to consider how developers like to work...
Estimates and commitments are opposites - with a commitment, the giver of the commitment is under pressure to deliver. With an estimate (an actual estimate, not "I'm using the word 'estimate' but I really want a commitment"), the receiver is under pressure to use that estimate to control the project to meet its targets. That's all an estimate is good for, so there is no other reason to ask for it... which is why hardly anyone does.
By definition, you can't negotiate an estimate. The subject of a negotiation is always a commitment, so if you know that the number you're going to bring to the table is going to be negotiated, make sure it's a commitment you bring, not your personal estimate. The time-honored tradition of "doubling and adding some" is simply the process of converting an estimate into a commitment before bringing it to the table.