Earlier quoted context omitted.
I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.
Was the intention to force people to break tasks down into smaller chunks? There's no way you're spending months on something that can't be broken down at all.
Why software projects take longer than you think: a statistical model (2019)
171–178 of 178 posts
Re: Why software projects take longer than you think: a statistical model (2019)
#172Earlier quoted context omitted.
It's undeniably true that estimates are often driven mostly by what number will be acceptable. But it doesn't invalidate the points the article makes. Even when this distorting element of business drivers are removed, estimation is still very hard. You might get reprimanded if you give accurate estimates - that doesn't change the fact you mostly can't give accurate estimates even if you wanted to.
> you mostly can't give accurate estimates even if you wanted to. Ah, an optimist. I long for a world where software development estimates and those who expect them are perceived as the unfunny jokes they are. Why do naked emperors make such wretched despots?
That being said, accurate estimates are usually not needed, but the order of magnitude is. Knowing if the change is days, weeks or years of work is important - and while we're bad at estimates, we're rarely "I estimated 2 weeks but it took 6 months"-bad.
Re: Why software projects take longer than you think: a statistical model (2019)
#173Earlier quoted context omitted.
If you gave accurate estimates you'd get fired for taking so long to produce those estimates. Ask your stakeholders how accurate each estimate needs to be and how much they want to spend on estimating. Where I'm at now a simple complexity score of 1,3,5,8,13 works fine and gives us +-30% variance and predictive power for new work when translating points into time spent after about three months of work and collecting…
A team I was once on would take 2-4 days to estimate how much work we could get done in the next two months. We were usually pretty close! The important thing to understand here is that we had complete buy-in from Management. This was part of our process, and they understood that we needed that time to do a good job of estimation and risk management. The problem in most organizations seems to be that no one is willin…
I think thorough planning and estimations usually makes for both better and faster outcomes, but I'm unlikely to push for it simply because a full day of planning (or more) every two weeks is pretty damn boring. Doing some light high-level planning and diving into things is less efficient, but way more fun even if you end up having to backtrack more etc.
Re: Why software projects take longer than you think: a statistical model (2019)
#174Earlier quoted context omitted.
The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y. The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to somethi…
Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.
Re: Why software projects take longer than you think: a statistical model (2019)
#175Earlier quoted context omitted.
A team I was once on would take 2-4 days to estimate how much work we could get done in the next two months. We were usually pretty close! The important thing to understand here is that we had complete buy-in from Management. This was part of our process, and they understood that we needed that time to do a good job of estimation and risk management. The problem in most organizations seems to be that no one is willin…
While that may be a reason, I strongly suspect the real reason is that engineers simply don't want to spend time estimating. In my experience most people think breaking projects down into small chunks and estimating each chunk is terribly boring, they'd much rather have bigger and less defined chunks so they can start coding faster. I think thorough planning and estimations usually makes for both better and faster ou…
OTOH, it's part of a quality process and if your organization is driven by the need to produce high-quality output, accurate size & effort estimations are a part of how you get there.
Re: Why software projects take longer than you think: a statistical model (2019)
#176 - Did you ever see any project finished ahead of time?
- How many project did you see where scope was shrinking during execution vs. expanding?Re: Why software projects take longer than you think: a statistical model (2019)
#177Earlier quoted context omitted.
> you mostly can't give accurate estimates even if you wanted to. Ah, an optimist. I long for a world where software development estimates and those who expect them are perceived as the unfunny jokes they are. Why do naked emperors make such wretched despots?
On the other hand, you really do need some kind of estimate. You'd never hire an hourly contractor to remake your roof if he refused to give any kind of estimate, why wouldn't the same apply to software engineering? That being said, accurate estimates are usually not needed, but the order of magnitude is. Knowing if the change is days, weeks or years of work is important - and while we're bad at estimates, we're rare…
To assist you, let me paint a picture to put you in the right frame of mind:
You have never worked with superconductors of any kind and you’re not even a physicist. You’re one of those “scientist types” that are indistinguishable in the eyes of account managers.
You’re in a thirty minute Teams meeting with a disinterested project mismanager that wants not just a finish date (on a specific date), but the milestone dates on the way there.
You haven’t even met the team you’ll be working with. You haven’t yet spoken with the customer. Your “requirements” (lol) is literally just three words.
Your “obstinance” at refusing to be professional and “do your job” is being thrown in your face by the PM and is being recorded for your next review meeting.
Replace “room temperature superconductors” with any one of dozens of IT technologies or tasks and you have a nearly verbatim replay of my career and my challenges with estimation.
Here’s the thing: if you’re doing something for the first time, you can’t estimate it. If you’re doing it a second time, you can’t estimate it either because it’ll benefit from reuse in a way not experienced the first time. If you’re doing things three or more times in IT, you had better automate the process… another unpredictable first-time activity.
You’re either a meat robot doing repetitive work best done by scripts or LLMs - or by definition you are doing things for the first time and can’t estimate accurately.
I don’t do the equivalent of putting down roof tiles in my work.
Do you?
Re: Why software projects take longer than you think: a statistical model (2019)
#178Earlier quoted context omitted.
My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.
> making the estimate pointless Did anyone tell them this?
None of these had any access controls, not even for which cells were editable. When I queried about the obviously misaligned pastes and no-content graphs rendering the reports useless, a couple people responded like "Yeah, we know the reports are crap. They want them anyway.".
This was at a company that "was continuously growing at ~3% since the founding" (some decades) and "had never laid off any worker, not part-time or temps".
But somebody had given up. Maybe the guy who came before me, who quit with little notice. A week? I don't remember.
I was given three months for creating and documenting a physical filing system (previous guy left no documentation), and physically filing the backlog. I made it take two weeks, including going back through old Excel workbooks and physical files to repair, correct, and apply access control on the workbooks.
For my next two weeks, I spent a tiny bit of each day keeping things updated, and the majority of it helping out in another department.
Then they suddenly laid off all temps, no appeals from supervisors accepted.
Fast-forward a few years, and I heard from an active employee that they very nearly foundered, before returning to profit, thanks to one of their largest customers taking some of their debt (calculating that their reliability and precision was worth more than the cost of trying to get any other supplier tooled, schooled, and proper rigorous).
I like to think I worked myself out of a job their, by making the estimates not pointless.