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.

Transcript

1. Building a Culture Where Software Projects Get Done Greg Brockman CTO at Stripe @thegdb
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