惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MongoDB | Blog
MongoDB | Blog
B
Blog
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
aimingoo的专栏
aimingoo的专栏
B
Blog RSS Feed
博客园 - Franky
V
V2EX
IT之家
IT之家
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
J
Java Code Geeks
F
Fortinet All Blogs
I
InfoQ
云风的 BLOG
云风的 BLOG
腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
月光博客
月光博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Proofpoint News Feed
Microsoft Security Blog
Microsoft Security Blog

JonahDevs

Building in Public: The ‘Back to It’ VS Code Extension – Part 1 Building in Public: The Time, the Silent Exploit: The Unseen Enemy in Every Codebase Time, the Silent Exploit: The Unseen Enemy in Every Codebase The Mindful Coder’s Workweek: 5 Themes to Enhance Your Craft and Satisfaction The Mindful Coder From Dirty Dishes to Clean Code: How Household Chores Mirror Programming Team Dynamics From Dirty Dishes to Clean Code: How Household Chores Mirror Programming Team Dynamics You’re Closer Than You Think: The Only 6 DNS Concepts You Really Need You The Wasabi Method: Shocking Your Way Out of Anxiety Attacks The Wasabi Method: Shocking Your Way Out of Anxiety Attacks Free Software: The New Nicotine? Big Tech’s Playbook Straight Out of Big Tobacco Free Software: The New Nicotine? Big Tech Your Gut is Smarter Than Your Spreadsheet: The Art of Software Estimation The Subtract Day: Why Less Code Can Lead to More Success The Subtract Day: Why Less Code Can Lead to More Success ESLint ESLint: Why We Actually Bother Understanding Nginx Part 1: The Power of Event-Driven Architecture Exercise Snacks: The Secret to All-Day Energy and Productivity How Important Clamping Is For Woodworking How to Fix Your Sleep Cycle Min/Maxing WordPress Hosting Min/Maxing My Internet Provider Everyone Uses Super Glue Wrong.
Your Gut is Smarter Than Your Spreadsheet: The Art of Sof...
Jonah · 2024-07-01 · via JonahDevs

Ever been in a meeting where everyone’s tossing around numbers like they’re psychic? Yeah, me too. Let’s chat about why your gut might be better at estimating than you think.

=SUM14.5×1.3?! spreadsheet gut most estimates live somewhere on this rope

Balancing between the spreadsheet and the gut

What’s the Deal with Software Estimation?

First off, let’s get real about what we’re trying to do here. We’re basically trying to predict the future. No pressure, right?

When we estimate a software project, we’re attempting to:

  1. Figure out how long it’ll take
  2. Guess how much it’ll cost
  3. Decide how many people we need
  4. Pretend we know what could go wrong

Sounds simple enough on paper, but we all know it’s about as straightforward as herding cats.

the manager's whiteboard Q3 launch 2 weeks "it's just a form, right?" the developer's timeline authedge casesmigrationsDave's approvalthe actual form precise "two to six weeks, honestly"

The manager's timeline vs. the developer's

The Estimation Paradox: Why Who Estimates Matters (But Shouldn’t)

Here’s a fun fact: who does the estimating can impact the estimate itself. Weird, right? It’s like asking different people how long it takes to boil water, and getting answers ranging from “30 seconds” to “three days.”

A study by Magazinius et al. (2012) found that estimates can vary wildly depending on who’s doing the estimating. Project managers tend to be more optimistic, while developers often lean towards pessimism. It’s like they’re estimating for completely different projects!

But here’s the kicker: the amount of work doesn’t change based on who’s estimating. The code doesn’t care if it’s being estimated by the CEO or the intern. It’ll take as long as it takes.

The “Massage the Numbers” Trap

We’ve all been there. You give an estimate, and the response is something like, “Yeah… but can you make it faster/cheaper/easier?”

It goes something like this:

  1. You: “Based on our analysis, this project will take 6 months.”
  2. Them: “We need it in 3 months. Can you revisit the estimate?”
  3. You: Sweats profusely “Uh… maybe 4 months if we cut some corners?”
  4. Them: “Great! 3 months it is!”

And just like that, you’ve fallen into the trap. You’ve massaged the numbers until they fit what someone wanted to hear, not what’s actually possible.

The Aftermath: When Reality Hits

Fast forward a few months, and surprise! The project’s running late, over budget, and everyone’s stressed. Who could have seen this coming? (Spoiler: You did, in your original estimate.)

A study by Flyvbjerg et al. (2002) found that 84% of software projects experience cost overruns. That’s a lot of stressed-out developers and unhappy stakeholders.

{ } $ if (?) ? "so… how long?" it never shows Dave from accounting

The crystal ball: code, clocks and dollar signs

The Secret Sauce: Experience and Gut Feeling

Here’s where it gets interesting. It turns out that your gut might be better at estimating than all those fancy spreadsheets.

A study by Jørgensen and Gruschke (2009) found that expert judgment (aka, your gut feeling based on experience) often outperforms formal estimation models.

Why? Because your gut takes into account all those intangible factors that models can’t quantify. Things like:

  • Team dynamics
  • The “unknown unknowns”
  • That one library that always causes problems
  • The fact that Dave from accounting always takes three weeks to approve anything

Precision vs. Accuracy: The Estimation Trap

Here’s a mind-bender for you: being more precise in your estimates can actually make them less accurate.

Think about it like this:

  • “This will take 3-6 months” (Less precise, more likely to be accurate)
  • “This will take 4 months, 2 weeks, and 3 days” (More precise, less likely to be accurate)

A study by Yaniv and Foster (1995) found that people tend to prefer precise estimates, even if they’re less likely to be accurate. It’s like we’d rather be precisely wrong than vaguely right.

Try it: type your gut estimate and see what an honest range around it looks like.

The Bottom Line: Trust Your Gut (But Verify)

So, what’s the takeaway here?

  1. Use your experience: Your gut feeling, based on past projects, is often more accurate than complex models.
  2. Be wary of precision: Broad estimates are often more useful than precise ones.
  3. Compare to past projects: Look at similar projects you’ve done before. They’re your best guide.
  4. Don’t massage the numbers: Stand firm on realistic estimates, even if they’re not what people want to hear.
  5. Keep learning: Every project teaches you something. Use that knowledge to refine your gut instinct.

In the end, estimating software projects is more art than science. It’s about balancing experience, gut feeling, and a healthy dose of realism.

So next time you’re asked for an estimate, take a deep breath, think about similar projects you’ve done, and trust your gut. It might just be smarter than you think.

Remember, the goal isn’t to be exactly right (that’s impossible). The goal is to be useful. And sometimes, a well-informed guess is the most useful thing you can offer.

Now, if you’ll excuse me, I need to go estimate how long it’ll take me to finish my coffee. I’m thinking somewhere between 5 minutes and 3 hours, depending on how many times I get distracted by shiny objects.