MicroPosts

  • How big things get done

    How big things get done published the following breakdown:

    • 100% of the mega-projects analyzed
    • 47.9% finished on budget
    • 8.5% finished on bugdet and time
    • 0.5% finished on budget, time, and produced the expected benefits

    Later, the book analyzes what are the prerequisites to get into the 0.5% Olympus:

    • Know why all the time: is this code rewrite benefitting the product?
    • Think slow, act fast:
      • Make mistakes in the planning phase when screw-ups are cheap
      • The more time the execution phase takes, the more you expose yourself to black swans (ie, catastrophic and unexpected events)
    • Mitigate risks:
      • Spike code to understand if and how something can be done
      • Ask people who worked on similar features what went wrong/could have been done better
    • Estimate using anchors:
      • Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
      • We always estimate with the happy case in mind and, even the most paranoid, cannot prepare for unknown unknowns
      • Ask others what was their experience building a similar thing and use their numbers as a starting point
    • Lean on experience:
      • Involve people who've worked on similar features in the past
      • Learn from other similar projects—and no, you are not working on anything so unique that cannot draw from experience
      • Use boring tech: "remove the words custom and bespoke from your vocabulary"
    • Build a team
    • Iterate:
      • "we're terrible at getting things right the first time"
      • "I have not failed ten thousand times," Thomas Edison said. "I’ve successfully found ten thousand ways that will not work."
      • "If something works, you keep it in the plan. If it doesn’t, you “fail fast,"
      • When talking about the success of the Empire State Building, "workers didn’t build one 102-story building, they built 102 one-story buildings."

    The following sentence made me stop and think about my fuck-ups:

    When delivery fails, efforts to figure out why tend to focus exclusively on delivery. That’s understandable, but it’s a mistake, because the root cause of why delivery fails often lies outside delivery, in forecasting, years before delivery was even begun.

PinkLetter

It's one of the selected few I follow every week – Mateusz

Tired of RELEARNING webdev stuff?

  • A 100+ page book with the best links I curated over the years
  • An email once a week full of timeless software wisdom
  • Your recommended weekly dose of pink
  • Try before you buy? Check the archives.