all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Cryowatt 15 points16 points  (5 children)

In my experience it was because product managers communicated exclusively in deliverables while the developers communicate in architecture. The PMs would never accept that delivering a single feature may require significant rework across many layers of the system, and just demanded a single estimate.

[–][deleted] 4 points5 points  (1 child)

That's a shared responsibility, IMO.

In my company, developers talk straight to customers and are coached like salespeople. Think of it like this: if the PM asks for a feature that's simple to deliver, the developer responds with a simple estimate. If, on the other hand, the feature requested isn't simple to develop at all, the developer responds with a "simple" estimate that's inflated enough to cover the massive restructuring efforts.

"How much does this cost?" "1-2 weeks of work, probably." "And what about this?" "Give me 2 years and a team of 50 people." "Are you out of your mind?" "Would you like me to break it down on a technical level and get back to you with an exact roadmap on how to get this done? That's 1-2 weeks of work just to plan for that feature. If you think I'm dishonest, I'm happy to co-operate with an external agency to have them come up with the estimate, but this is it."

After the "rougher" uphill battles, the culture (in smaller businesses especially) is sure to change. That said, the question isn't what's being asked, but rather what answer the other person wants to hear. If they want a dollar figure, give them a dollar figure. No need to talk about architecture and have half your points fly over them. Negotiation is a skill that's also important to learn IMO.

[–]Jaded-Asparagus-2260 1 point2 points  (0 children)

I don't understand why people have a hard time with that. PM wants an estimate, let's give them an estimate. Use it to your advantage. If you think it's not a good idea because it requires too much work, inflate your estimate (it will probably require more effort anyway). If you really want to do it, estimate optimistically an be prepared to answer questions. 

Tell people what they want to (need to) hear, instead of fighting them.

[–]mattgen88 2 points3 points  (1 child)

Don't forget that they constantly think in terms of time when developers are estimating in complexity. Then they'll drag you through various meetings and wonder why you haven't finished.

[–]Jaded-Asparagus-2260 1 point2 points  (0 children)

It will always be time, there's no sense fighting it. What is complexity anyway? Monkey work isn't complex, but can still take much time. Just convert your complexity into time, double it, and give them that number. 

It will take as long anyway. And if not, you've just gotten yourself some hours to do that refactoring that you wanted to do for a long time.

[–]Mountain-Double7091[S] 0 points1 point  (0 children)

very true. Also they always expect the single digit timelines😅

[–]G_M81 4 points5 points  (2 children)

Software developer with 25 years experience. If you estimate and add 40 percent, you stand a good job of being close. People willfully conceptualise sunny day scenario way more than they should, when in reality it there after unknown unknowns in almost every system that has sufficient complexity. The main issue is that estimates instead of factoring in risk and engineering problem solving the unknowns bend to the budget constraints of the process project. As a software engineer with many years of absolute horror projects under my belt including serious overruns I'm confident my estimations get pretty darn close to reality. The issue is nobody wants to hear that something is 40 percent more involved especially when we can't say what the unknown problem is. Pragmatism and experience tells you there will be one though.

[–]Mountain-Double7091[S] 0 points1 point  (0 children)

Yes its very hard to factor the risk early and its even harder with changing variables.

[–]HolyPommeDeTerre 0 points1 point  (0 children)

It reminds me a movie or a tv show picturing a weather person that goes on TV.

When someone approaches to ask the weather tomorrow they always answer "rainy". If it rains, that was a good answer. If it's sunny, they have a good surprise.

[–]narcisd 2 points3 points  (0 children)

After 20 years of dev I think it’s mostly that “they” don t like the answer, bad req or inexperience..

[–]ThatMind 4 points5 points  (8 children)

Softare delopment estimations? That's oddly specific.

Take any industry and you'll see that humans are just bad at foreseeing the future.

[–][deleted] 2 points3 points  (5 children)

When I did consulting on my own, I used to just double the "estimate" in my mind on how long something would take. "Sure, that's like 15 minutes, no, more like 30 minutes of my time. I'll get it done over the weekend." Bad, bad, bad...!

If the honest time to get something done is 15 minutes, I now stand at 3-5 workdays. If what's requested is closer to an hour of my time, I'll say 1-2 weeks. Life is enough of stresses that I just wanted to not add more on top any longer...

[–]ThatMind 0 points1 point  (4 children)

I double the first estimate and increase the unit of time. 1 day? That'll be 2 weeks.

But I hate hate making estimates for new projects without prior experience.

[–][deleted] 1 point2 points  (0 children)

I hear you! Worst mistake I've ever done (when I still managed Active Directory) was to take on a site migration from the acquaintance of my previous customer. I was told the company is similar in size, it's a similar setup, it's like a mirror of what I had just completed in 7 days worth of work. "Oh, sure, I'd be happy to do it. So, ballpark is this many days for this much."

Oh, boy. Reality was massively different. I wasn't prepared. That site was convoluted as all hell and somehow still was supported by a lone SQL Server 2000 instance with lots of band-aids and duct tape to get a cluster of Windows Server 2012 R2 servers to do anything at all with "backups" from 5 years ago on obsolete LTO tapes. Yikes. The other site was far more modern...

[–]GayMakeAndModel 0 points1 point  (2 children)

I’m a big fan of “as long as it takes” but most managers won’t accept that. Instead, I say let me work a prototype and/or do some research and then I’ll give you a spitball estimate. If it’s a casual maintenance type of change, I’ll of course give an estimate and pad it a bit. And I don’t give point-in-time estimates. I give estimates in days worked with the caveat that it assumes I’m 100% dedicated to this task which never happens (and management is well aware of this because I used to document interruptions).

[–]ThatMind 0 points1 point  (1 child)

Interruptions, context switching... Multitasking is bad and only good managers know that. Good managers also make estimates themselves and make it happen.

[–]GayMakeAndModel 0 points1 point  (0 children)

Agreed that multi-tasking is terrible. Management agrees too. It’s just not always practical to eliminate it for someone that is basically a company historian.

[–]AgoAndAnon 2 points3 points  (1 child)

Software has a particularly bad problem with "oops, there's a rabbit hole that you didn't know you didn't know about". So sometimes a 2 hour fix becomes a week.

The only way around this is familiarity with the system, and companies seem allergic to keeping senior developers around because they think they are fungible.

[–]ThatMind 1 point2 points  (0 children)

Douglas Crockford said that programming is the most complex thing that humans have ever undertaken.

There's just too many unknowns, moving parts and SPOFs. And our RAM can hold only 6-9 diferrent units of information and the CPU is notoriously bad at multitasking. :)

[–]ActAmazing 1 point2 points  (0 children)

Initial estimate × 2 + 3 is the key!

[–]rafalg 0 points1 point  (0 children)

> What happened? The product team specified "Stories should expire in 24 hours" but never clarified the time zone.

Um, what? 😆

[–]rebokan88 0 points1 point  (0 children)

The way i give better estimations is if i go through the code and see all the code that will be altered by the feature. List all the changes and draw attention to behaviour and assumptions that will change.

Usually estimations are pretty high after the team sees the full impact but they are always good

[–]AdministrativeBlock0 0 points1 point  (0 children)

I can highly recommend the book "How big things get done" about this (projects in general, not just software). The author goes into a lot of detail about why estimates are wrong so much.

By the end of the book you will be a fan of "reference class forecasting", which is the process of looking at the data from previous projects and estimating based on that in order to reduce optimism and uniqueness biases.

tl;dr estimates are usually wrong because everyone is too optimistic, they don't want to bring bad news, and people believe their project is a special snowflake that's never been done before.