Building a Culture Where Software Projects Get Done

9d8b3e8c6babffda3cf50cc1ff8c871e?s=47 Greg Brockman
November 13, 2013

Building a Culture Where Software Projects Get Done

(My slides from http://qconsf.com/presentation/building-culture-where-software-projects-get-done)

Software engineering has existed as a discipline for over fifty years, and still people continue to fall into all of the classic engineering fallacies. Rewrites fail with high frequency, feature creep smothers nascent projects, and engineering timelines get repeatedly pushed back until they are all but meaningless. None of these statements are surprising, but what's surprising is that great engineers who are very aware of these pitfalls can ensnared by them anyway.

In this talk, we'll go over how we've structured the culture at Stripe to avoid these traps. We're certainly not immune to the classic fallacies, but each time a project goes poorly we adapt our workflow to mitigate the relevant failure mode in the future. We'll describe the principles driving how we approach software projects (and the history of how we discovered them), as well as why it's important to bake these ideas directly into the culture.

9d8b3e8c6babffda3cf50cc1ff8c871e?s=128

Greg Brockman

November 13, 2013
Tweet

Transcript

  1. Building a Culture Where Software Projects Get Done Greg Brockman

    CTO at Stripe @thegdb
  2. None
  3. We don’t know how to build software

  4. EXPECTED Disappointing Insane Today LIKELY Engineering timelines will slip

  5. System complexity never decreases

  6. Rewrites will always fail (that doesn’t stop people from trying,

    though)
  7. You are not special

  8. Choose wisely how you’re spending your time

  9. Roll your own solution to your hardest problems, not your

    easiest ones
  10. Balance creation versus maintenance

  11. 5.times {print “Automate”}

  12. Once a bug is triggered, it will keep biting you

    on a short timeline, no matter how unlikely it seems
  13. Invest in technology to support your rate of change

  14. Tests aren’t for your benefit

  15. Create a technology monoculture

  16. You will have technical debt — and that’s good Image

    Credit: Philippe Kruchten
  17. Pick a few standards

  18. Have checks and balances against yourself

  19. Minimize distance to the first production use Time to shard

    everything: 3 months (projected) ! Time to shard internal collection: 1 week
  20. Have assumption questioners

  21. Bus factor: not just for bus accidents

  22. Use forcing functions (cautiously)

  23. Have a good launch process in place

  24. Have good post-hoc processes in place

  25. Make collaboration great

  26. Find communication sidechannels

  27. Documentation should not be a primary source

  28. Meetings: useful but costly

  29. Have design dictators

  30. Have lots of remotes or no remotes

  31. Greg Brockman gdb@stripe.com @thegdb