101–110 of 212 posts
It'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…
+ c constant.
It'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…
Hmm, so with 0 mechanical keyboards, it's zero?
It'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…
+ c constant. Everyone forgets the constant all the time.
Earlier quoted context omitted.
When the problem can never be resolved, you redefine the problem until you find a version of the problem with a good solution. So if the problem is that software is hard to estimate, which is hard, we redefine the problem to something like “I want to be able to ship something people want to buy, before we run out of money” or “I want to ship a game in time for Christmas” or “I want to reduce operating costs so we don…
> “I want to be able to ship something people want to buy, before we run out of money” Buddy, if I knew the answer to the question "something people want to buy" I would be rich already
Software effort estimation is mostly fake research - https://news.ycombinator.com/item?id=25825244 - Jan 2021 (308 comments)
A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you c…
Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine.
And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An economist can’t take a software problem and decompose it into tractable solutions. Even if they could - good luck getting the customer to pay for that.
That’s why I say estimating is an economic problem. The cost of accurate estimates asymptotically approaches the cost of the implementation. Nobody is willing to pay for accurate estimates, and anyway doing this doesn’t make sense.
Unfortunately there are very few levers to pull in terms of software planning. Time based project management is way over emphasised. This is why approaches like lean (MVP, CD) and agile exist in the first place.
I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…
> money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. That's a non-sequitur. there are plenty of ways to run a project under a budget that don't involve deadlines.
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…
Most commercial software projects that I’ve worked on start with a horrific RFP process and legacy integrations that make otherwise simple projects into bespoke nightmares.
The whole process of commercial software procurement and project assurance is a mess.
And then you get consulting firms and body shops involved…
Earlier quoted context omitted.
Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit. "hmm, adding that button probably takes about an hour"... 2 days is about right. Almost 30 years later I still find this to be true. Truer than I like.
So 1 Month becomes 2 years? I don't think that's a good rule.
- You’ll get a bunch stakeholders each requesting a different format of progress reporting.
- You’ll get pulled into dealing with a small but disruptive emergency that requires unique expertise.
- A dependency will change in a way incompatible with your work in progress.
- You’ll hand off the half done project to the new hire.
- You’ll need to rediscover what the project is about after the new hire hands it back.
Earlier quoted context omitted.
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…
Get out of the company if it has this kind of management.