6 ms·
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
by keyle 3y ago
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 by the room temperature multiplied by the amount of people with mechanical keyboards.
That gives you roughly the right estimate for any job, until the next sprint.
- drunkenmagician 3y agoWait! this is my method, and its patented! You need a licence sir ;)
- cardy31 3y agoIn this vein, my manager doesn’t appreciate when they ask for an estimate and I say “If I knew how to accurately estimate software projects I would be making millions as a consultant. But I don’t so I’m here”
- catchnear4321 3y agolikely because of your assumption that high paid consultants make accurate estimates. they do get paid more.
- cardy31 3y agoNo my assumption isn’t that consultants make good estimates. It is that nobody in our entire industry knows how to accurately estimate how long a software project will take, so I would be a highly sought-after rare commodity in our industry.
- eftychis 3y agoThe 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 later I learned they were still working to finish it. Another example: they wanted a Byzantine Fault Tolerance rewrite along with the networking layer. I said we need 6 months. They said we know how it should be done in 1-2 months. I finished my stuff and moved on — they picked couple of people to work on the rest that had said 1-2 months. It took them a year to reach a point they could test it. Now why did I say 6 above? Because that is a project I have done multiple times, I can do everything in my sleep and the delay beyond all other fundamentals is random interruptions. Did that matter? No. When top head works with wishful thinking estimates are ways to find scapegoats; nothing more.
- senttoschool 3y agoI 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.
- hinkley 3y agoI think at least a lot of them are rudely surprised. If it’s a conspiracy not everyone is in on it, at least. There’s more an element of believing your own PR in many cases.
- jahewson 3y agoIn my experience the 2 month version is so bad it’s still being hotfixed in production in month 8.
- MrPatan 3y agoThat's a success story. The 2 month version could be sold at all, the 6 month one can't, so it's not worth considering its technical merits. Then the client/stakeholder buys in, the sunk cost, well, sinks in, and things get fixed. Success!
- smileysteve 3y agoThe 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"
- 3y ago
- Farox 3y agoMany, 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.
- Phlogi 3y agoSo 1 Month becomes 2 years? I don't think that's a good rule.
- dmacedo 3y agoNot that I've used this extensively, but months would likely increase to quarters. And if you're estimating something to the lengths of months, you're already into project management territory size, rather than broken down to development/delivery sizes... The amount of unknown unknowns and other uncertainty certainly warrant happily estimating years length, surely. Also #NoEstimates (=
- lrem 3y ago1 month of your own concentrated work? 2 quarters easily, because at this scale: - 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.
- hinkley 3y agoIt is somewhat a self correcting system. You don’t want them interacting with you too often for one hour tasks. You want to train them to lower resolutions slices. And you want to round up small ones to do refactoring as well. Eventually they get a sense of just right. It’s never perfect but they are estimating before they even ask. Whic if we’re honest, they’ve done anyway and they’re hoping we will agree, absolving them of the responsibility.
- adastra22 3y agoyou forgot to multiply by pi
- MathMonkeyMan 3y agoThese are CGS units, not SI.
- nsoonhui 3y agoI 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?
- keyle 3y agoIt was a satire. My go to formula is actually (A * B) / C + 2^D + (rand(4, -4) * E) / (0.5 * F) [A] Time if I did it all by myself [B] I have no idea what I'm doing ratio [C] I totally have done this before [D] Amount of weekly WTF per code review [E] That stakeholder couldn't hold a stake [F] Likely hood of it changing by next week
- TeMPOraL 3y ago> 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 project a one-off job in an unexplored environment.
- deleted 3y ago[deleted]
- prionic6 3y agoI just use the 80 20 rule: - estimate at least 20 days - multiply by 20
- jmorenoamor 3y agoWait, are you estimating without taking into account the moon phase? Good luck with that.
- TeMPOraL 3y agoWell, they said it's a rough estimate.
- trashtester 3y agoHmm, so with 0 mechanical keyboards, it's zero?
- keyle 3y agoSure, there is always that no-code solution!
- not_your_vase 3y ago+ c constant. Everyone forgets the constant all the time.
- someweirdperson 3y agoAlso some exponent, anything from ^2 to ^x, especially if multiple persons are involved.
- NoMoreNicksLeft 3y agoYes, 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 story points to the tickets. That's why he's on fast track to lead senior developer. He knows what's important. I'm trying to help you learn what's important too, but you've got to want to be helped.
- keyle 3y agoHah! 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
- mtlmtlmtlmtl 3y agoYou forgot to factor in the Pointless Meeting Frequency Coefficient F(U) = (#MBAs in company)^(# of middle management levels)
- kleene_op 3y ago> multiplied by the amount of people with mechanical keyboards With negative weights for keyboards with cherry mx blue.
- TuringNYC 3y agoI've found if you give realistic estimates, some contracting firm comes in, offers to do it in half the time, grabs the project and then takes 2x longer. Finding stakeholders competent enough to understand this pattern is important. If not, you might as well throw out any estimate and also take longer.
- davely 3y agoHah! One of the knocks against me in my last performance review was that I had poor time estimation for completing tasks. I asked my lead for help in getting better at this and they were basically a real life version of the Neil deGrasse Tyson hand waving GIF.
- KineticLensman 3y agoYou forgot "round it up the next order of magnitude"
- smif 3y agoDon't forget to multiply by the square root of 2 (management overhead coefficient). Also note that this is an irrational number so it has a subtle jab at management built-in.
- yibers 3y agowhat if the room temperature is 0?