Live data from Hacker News

Software effort estimation is mostly fake research (2021)

shape-of-code.com

151–160 of 212 posts

Re: Software effort estimation is mostly fake research (2021)

#151

Earlier quoted context omitted.

I don't disagree with you but I think people also need to understand that management often pick the team that provides lower estimates because team members will have to work harder to deliver it. Management might not be so dumb. If someone said 2 months and you say 6 months, they might go with the person who said 2 months but will accept 5 months secretly.

In my experience the 2 month version is so bad it’s still being hotfixed in production in month 8.

The 2 month version experiences scaling issues at a 20% rollout, or takes 20s for a database query before returning a page.

In 6 months you need a better scaling version while the current version is creating cascading database failures; it's got terabytes of denormalized data that is out of sync and a 2nd team can't migrate the data in 12 months.

In 12 months, you find 5 other teams copied the 2 month solution.

In 2 years, you have 0 devs left that can solve the problem and a 1000% grown dev team that is great at the 2 month solution.

You ask the teams why they don't use the scalable solution and they say, "do we have any examples of that, the unscalable way is our convention"

Re: Software effort estimation is mostly fake research (2021)

#152

Earlier quoted context omitted.

The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…

Your first mistake was misunderstanding the relationship with management. Time estimations are bargaining, you ask for something and then get a counter offer from management, they don't care that the counter offer from them is delusional. The bargaining is the point, the less time you bargain for the more stressful the development can become. Don't estimate what it should take, estimate what it could take and bargain…

The other part is that management/PMs usually care about deadlines, not work effort (duration in man-hours, story points, or whatever).

Allow me to indulge in a fictional narrative:

You are handed "high level" (a.k.a rooted in the fuzzy non-technical alternate reality that is product management) requirements resulting in known unknowns and unknown unknowns. You're junior and naive and you put real tech-borne effort numbers in front of each task; or you're experienced and you put O(t) numbers on the first ones and random but high numbers on the second ones.

Anyway, the estimates end up landing past the desired deadline, management mutters TLAs such as "OKR" and whatnot, you'll have to justify why it doesn't fit, so you communicate work effort.

You are summoned into a retroplanning meeting to cull out stuff based on work effort so that it fits management's expected deadline, and try to pretend you're doing agile when it's all waterfall Gantt in disguise.

Project starts. Implicitly man-hours become wall-clock-hours, irrespective of other tasks such as CI/tooling/dependency breakage, code hygiene, or customer support escalations; your effort estimates became t{project start}+effort == deadline. You are now held accountable for the latter based on you communicating the former.

Time is now the scarcest of resources, you do your best, conjure magic, work extra hours, take shortcuts, and make it to the deadline, sacrificing body and soul. In a cloudy spreadsheet checkboxes have been checked, management is happy. Deployment is smooth but soon corner case bugs and escalations start trickling in. Management is either oblivious or not so happy after all.

Time for a new quarter to start. You know issues borne out of past quarter will rear their ugly head, and there's much tech debt to repay before interests quickly accrue towards tech bankruptcy. You're junior and swear to yourself to not make the same mistake, and you start inflating numbers; you're experienced and you realise the whole number dance is a sham as they don't matter anyway, but you still are required to do the dance because that's how the game is played, so you turn Scotty and just throw outrageously big numbers up in the air and just make sure the deadline is not too ludicrous, still hanging to the hope hoping that someone, somewhere, has seen the light of reason and built a company around it, and maybe you could go to these greener pastures; you're very experienced and you realise the only winning move is not to play, so you quit (not the job, the _industry_) and move to a remote plot of land with literal green pastures and a small cabin mountainside to raise sheep, or cut wood, or whatever, where the smallest time unit is the measurement error of eyeballing the zenith-relative angular position of a giant fireball 8.3 light-minutes away.

Re: Software effort estimation is mostly fake research (2021)

#153
post #6

Ran a successful digital agency for years. Estimation was mostly guesswork. There’s a theory that work expands to fill the time you give it and I found that to be largely true. Other agencies would quote 3 months for projects we’d complete in 6 weeks. Even then I was taking engineers 3 week estimates and doubling them for buffer. We didn’t do anything special other than commit individuals to a single project, or two…

Similar point. I’ve been running an agency for 14 years. All that time we’ve tracked hours for every project whether T&M or fixed bid. Now when a project comes in for bid I always estimate it based on experience but then validate it against one of 250 projects we’ve done that seems “similar” in scope. Since doing that we’ve only been off significantly when we misunderstood the original scope. Tracking hours is a pain…

> Tracking hours is a pain in the ass and we do it mostly in Jira tied to tasks but the data we get is invaluable.

The important point here is to actually feed that information back to the people that originally did the estimates and also to the people that are (to them) "pointlessly" clicking on the "start work", "stop work" buttons on their JIRA tickets.

Most of the time, this sort of timesheet stuff is fed to an accountant somewhere that turns it into magical "earned value" based on inaccurate project schedules that are always 99% complete but with a vertical S curve.

Re: Software effort estimation is mostly fake research (2021)

#154
post #114
post #24

Earlier quoted context omitted.

> We are building Sydney Opera Houses. Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market. In reality, most devs are making unique family Vilas at best. I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.

I might be mistaken but Sydney Opera House is brought here (as it often is) in context of project management as a heavily underestimated project (took 15 years to build while planned for 4, cost ~15x of original estimate) - not in the context how detailed and greatly architected it is. There are deep analysis from the project management perspective but one point was that initial estimates were based on historical ass…

It also leaves out the political machinations that a conservative government was elected after the project had begun under a centre-left government and they continually interfered in the development until the original architect left the project in disgust.

After which the internals were completed by a set of "government architects" that did as about a good a job as you'd expect.

Not to mention that the original design had its own issues, including not actually being able to support proper opera theatrical performances due to the size and structure of the internals.

Re: Software effort estimation is mostly fake research (2021)

#155

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of s…

Re: China train example.

Now do a California rail from San Francisco to LA.

Answer, you can't. Earthquakes, Land Acquisitions.

Src https://www.washingtonexaminer.com/opinion/california-imagin...

Re: Software effort estimation is mostly fake research (2021)

#156

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of s…

It helped that China could throw essentially an unlimited budget and unlimited workforce at the job.

It ended up incredibly over budget and the various state owned corporations have had to be bailed out.

On the other hand, China now has a rail industry that allows them to sell around the world.

So the ROI over time is probably good. China can invest for the long term.

As Deng said, when asked about the French Revolution being good or bad, "Too early to tell."

Re: Software effort estimation is mostly fake research (2021)

#157

Earlier quoted context omitted.

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of s…

Re: China train example. Now do a California rail from San Francisco to LA. Answer, you can't. Earthquakes, Land Acquisitions. Src https://www.washingtonexaminer.com/opinion/california-imagin...

Run an elevated train along I-5?

There are no engineering solutions to earthquakes? Railways can be repaired.

Land Acquisition is a government and regulatory issue, not engineering.

Re: Software effort estimation is mostly fake research (2021)

#158

I might be in a 1% of engineers that believe in estimation. Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possible, it is that you are simply not experienced enough. That's fine. There is something called skills, and you can go get them. Have you made a plan? Great, then is there is some task in your plan that you can't estimate? In rare cases that might be inherently t…

Go look at the SysMLv2 spec. I want you to implement me a parser for it in Python. The resulting AST must respect the relations between fields defined in the standard. How long will it take you? It's just implementing what's written in a pdf, shouldn't be hard to break down and estimate. I'll wait.

Re: Software effort estimation is mostly fake research (2021)

#159
post #29
post #21

Earlier quoted context omitted.

Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.

I.e. spiral https://en.m.wikipedia.org/wiki/Spiral_model

Sigh, this was the basis of "Iterative Development" that came along with the "Rational Unified Process" and was the precursor to the current fad of epics/stories/sprints/t-shirts/Fibonacci that has polluted current programming.

People won't follow it because it means reviewing their assumptions and re-planning, but there are always external entities that will not or can not do so (other departments, finance, customers, marketing, sales, etc etc).

Re: Software effort estimation is mostly fake research (2021)

#160
post #61

At least when I was younger I was so perplexed by the kind of co-workers that have apparently chosen the profession of working with estimates from other people but continually work without a "confidence level" associated with each estimate. ("two weeks") means such a different thing in reality from ("two weeks", "confidence of 50%"). It's a tuple, it's always been a tuple, it's just downright silly to accept an estim…

It doesn't get better with magic values like confidence levels either

If you feed the confidence levels into a GANTT chart, then that shows up as slack when doing the critical path analysis.

But no one does that sort of thing anymore.

Post reply on HN