The Programmers Who Want To Get Rid of Software Estimates

An anonymous reader writes: This article has a look inside the #NoEstimates movement, which wants to rid the software world of time estimates for projects. Programmers argue that estimates are wrong too often and a waste of time. Other stakeholders believe they need those estimates to plan and to keep programmers accountable. Is there a middle ground? Quoting: "Software project estimates are too often wrong, and the more time we throw at making them, the more we steal from the real work of building software. Also: Managers have a habit of treating developers' back-of-the-envelope estimates as contractual deadlines, then freaking out when they're missed. And wait, there's more: Developers, terrified by that prospect, put more and more energy into obsessive trips down estimation rabbit-holes. Estimation becomes a form of "yak-shaving" — a ritual enacted to put off actual work."

Comments

Predicting the future is hard

[Krishnoid]

Joel Spolsky has a take on this problem, called Evidence-Based Scheduling, which tracks past estimates against their deliveries, and uses that to improve future estimates.

Re:Predicting the future is hard

[Sklivvz]

I work for Joel Spolsky and we have a single estimate: 6-8 weeks.

Estimation is basically useless because it has the unspoken assumption of "perfect design", which is an invalid one: software development is not a repeated exercise, it does not have consistency.

Having a single estimate does this to your projects: much smaller things, just do them; much bigger things, they are too big so don't do them, things vaguely in that scale, do them iteratively but define what you are trying to achieve in writing so you know when to stop.

No project managers, product managers work at a way higher scale (decide which are the projects worth working on).

Re:Simple methodology

[lgw]

You can't really give a good estimate up front on most projects, because even if the requirements are well defined (and they rarely are) they will change.

That's all OK. That's the whole point of Agile, if you ignore the Agile BS that consultants sell. You can quickly do coarse-grained task breakdowns (say, to 2-week tasks) to get a reasonable estimate of the work as you currently understand it: that estimate is generally within a factor of 2, if the requirements don't change, so you can at least see if you have 1/3rd the staff you need or something way off.

Then you measure real progress against that first-take estimate. Usually by about 6 weeks in on a team-sized project, you'll have the real multiplier. "We thought the first set of tasks were 20 programmer-weeks, but really as we understood it it was 30", and multiplying that initial "6 months" estimate by that measured 1.5 multiplier is a damn good estimation method. And it only gets better as work goes on. I can reliably give fairly accurate estimates from project completion now, on Agile projects, by the time we're about 1/3rd of the way done (and that's so much better than some teams are used to that it seems like magic).

Selling that all properly to management is a different thing, but that's a whole job skill that any senior engineer just needs to have. Just like showing management the cost of each requirements change, as well as the skill to minimize that cost of change (which is the real point of Agile- the rest is hype).

Re:Well someone has to do it

[boristdog]

IF managers listened to the developers.

My last major project:
Manager: What resources do you need for this project (Replacing a huge, entirely file-based factory product manufacturing system)
ME: At minimum, I need two more people, plus someone to take over most of my smaller duties. And a couple new DB servers.
Manager: How long will this take?
ME: Two years minimum, since we are replacing an entrenched 15 year old system.

Manager's report to director: He can do it by himself in 6 months.

3 months later:
Manager: Why isn't this finished? You started over a year ago!
ME: I started three months ago, you gave me nothing I asked for and you've given me several other projects since then that you said were higher priority.
Manager: Well stop wasting time and get to work! I told the director it would be done by now!
ME: You gave me nothing. At least let me have a CS temp.
Manager: There's a woman in finance who has a sister that might want the job. She knows Excel really well, she can probably learn databases and programming.

Aaaand I think we've all been there.

Fortunately the sister didn't want the job and I got a great college grad as a temp. I would not have finished the project (in two years) without his help, we hired him after a year, too.

Re:Simple methodology

[Maxo-Texas]

I had no particular problem with estimates.

At a minimum, you could break out easy "construction/recognized pattern" work from risky new stuff.

As far as managing programmers... it was humorous.

Few liked giving estimates. So they would say it couldn't be estimated.

So I would ask, will this project take 2 years... and they would say, "oh no- of course not" and after a bit, we'd get down to 6 months or 6 weeks or 6 hours...

So then we'd time box it to what could be done in a month and move any risky items up to the front so we could establish if a new technology wasn't going to work before we put a lot of work into the project.

Then, I recorded over/under for every project and found (over about 24 programmer data set) that programmers consistently overshot or undershot their estimates. So after a few projects, I had a pretty good idea of their deliverables.

Finally status reports and status meetings with function points and overall percentage delivered kept things on schedule or let us know well ahead of time there was a problem with the estimate/schedule.

Programmers were not my problem- executives were.

They...
a) pushed us to violate standards.
b) ordered overtime without ordering it. As in assign 80 hours work and then insist it be completed when everyone knew it couldn't be completed. Made worse by the fact the indian contractors said "I'll do my best" for "no- you are batshit crazy" and then things fell apart when the indians were unable to deliver. Of course, the indians were very good at delivering to the (crazy/incomplete) specifications on time. At least enough to be testable. I'm not sure if it is because they were contractor types or that they were indian- perhaps a bit of both. I learned in a contracting shop, you always say you can meet the estimate (to get assigned the work) instead of giving a realistic estimate. Then renegotiated it later when it wasn't going to make the schedule. If you didn't, then the three other people bidding on the work would get the work. Executives seemed to have zero memory for the fact that you delivered on time on estimate while the other people were usually late.
c) made everything priority 1a. they had no ability to prioritize as far as I could see. Which really just pushed prioritization down to me or the programmers.
d) cancelled projects without warning.