the point of estimation is the estimating activity that allows you to prioritize the task over others, not to end up with a useful document
Software effort estimation is mostly fake research (2021)
191–200 of 212 posts
Re: Software effort estimation is mostly fake research (2021)
#192Earlier quoted context omitted.
>>>. The real problem is not with estimation but with the management denial. ^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.
> Management already has a deadline fixed The real problem is saying "yes we can do it all in that timeline" instead of saying "That's fine, but we won't get to everything. We will work with you to prioritise the most important things to get done in that time." I know it's painful, but just hold that line. It's not lying or negotiating or padding; in fact it may be the only true statement you can say. If a civil engi…
You have to get them to take that perspective. What happens is "we want all this stuff how long is it going to take" and then they fight that number down while not answering any clarifying questions. So you have to sumo wrestle a bunch of assholes twice your weight into even framing the context correctly before the conversation you recommend can even take place.
Re: Software effort estimation is mostly fake research (2021)
#193It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
You forgot "round it up the next order of magnitude"
Re: Software effort estimation is mostly fake research (2021)
#194Interesting that most of the top comments here seem to be about the day to day process of estimation itself, when the linked article is about how poorly the research on estimation has been done to date. Did any of you actually read the article?
Glad I am not the only one who noticed this, thought I was reading the wrong thread. Software engineering research is something I was interested in a long time ago, so hoped for a better, more on-topic discussion.
Re: Software effort estimation is mostly fake research (2021)
#195Earlier quoted context omitted.
I can't tell you are serious or satire. If you are serious that kind of estimate is as good as useless because the projects most likely won't be profitable. Can you imagine what will a property developer think if he is informed that his project is going to take at least twice as long to complete?
> Can you imagine what will a property developer think if he is informed that his project is going to take at least twice as long to complete? Property developers aren't doing R&D jobs. Most of software development is a multiplayer life sciences R&D, because even if you're not developing new technology, the combination of your chosen stack, target market, stakeholder personalities and management policies, makes your…
[deleted]
Re: Software effort estimation is mostly fake research (2021)
#196I once developed an „AI“ trying to predict when JIRA tickets in our startup get resolved. It was mainly a system based on k-nearest neighbor regression, predicting the closing date based on the average of k similar tickets (we had more than 1000 closed tickets already). It worked reasonable well. One of the most important features was the person creating the ticket. Some people wrote tickets really well and the tickets often got resolved in 48h. Others just wrote one cryptic sentence and nothing happened with these tickets for weeks.
But you need a lot of high quality data for that. Since that time I realized that writing wellformed tickets and also changing their state on time is really important for such tools. Modern tools actually don‘t use KNN, but some of them use Monte-Carlo-Simulation to estimate work:
https://kanbanize.com/kanban-resources/kanban-analytics/mont...
https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
I believe used correctly these tools work better than all those scrum-pokers and t-shirt size manual estimation.
Re: Software effort estimation is mostly fake research (2021)
#197I've started to use the Log-Normal distribution for estimation. Because I think of development like planning a travel time, the train will either arrive in time or the will be a random amount of interruptions/errors that add up. But there won't be as much stuff that speeds the train up (wins back some time). Then I try to communicate the distribution in words or show it, which most often has a hard time to be accepte…
Re: Software effort estimation is mostly fake research (2021)
#198The best estimate for how long it will take to build X, is to build X many times -- under randomised control conditions -- and take an average. Anything short of this isn't amenable to the scientific method.
Lots of life depends on information discovered without the scientific method.
I agree.
Re: Software effort estimation is mostly fake research (2021)
#199Earlier 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…
Management denial is not universal. It can't be - companies that have realistic management should out-compete companies where management is politics and unreality. The problem is that management unreality can take a decade or several to destroy a place. But when you see that kind of management, know that that's the road they're on. That's your cue to start looking for somewhere with management that at least tries to…
I hope you are right. I have never been in or seen a workplace where management is not playing the 'get the order at (nearly) all costs - let others handle the problems' game. Again, I hope I am wrong. But these type of companies seem to outcompete all others. The only unicorn in a decade in my geographical area, is a company that plays this game very very well in the IT sector. As far as I have seen, they play a variation called 'the customer takes the problems (and the full financial impact). Due to building a good set of core competencies, that the competition mismanaged over years, they can get away with this strategy.
Re: Software effort estimation is mostly fake research (2021)
#200It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Yes, but how many story points is that keyle? Please be sure to use Fibonacci sequence numbers. If you don't give the ticket story points, we can't track the velocity of the sprint, and all our planning will fall apart. I know you like to complain alot about how your cubicle roommate doesn't understand basic control structures and the difference between floating point and integers, but he, unlike you, always adds sto…
Hah! Great question. And we don't use Fibonacci. We use the true answer to everything in the universe
42 seconds
42 minutes
42 hours
42 days
42 weeks
42 months and my resignation