The Developer Coefficient

Have you seen Stripe’s The Developer Coefficient report? I’ve been thinking about it lately in how it can relate to high assurance computing, and the sort of projects that end up in that space.

There seems to be an overall picture of

  • Developers spend the majority of their time on the “wrong thing”
  • Increasing the productivity of developers is a huge concern
  • Developers are allocated too little time to address bad code
  • Developers spend a lot of time maintaining existing code
  • Developers spend a lot of time changing existing code
  • Developers spend too much time managing change
    • Convincing themselves that there’s no regression
    • Convicing themselves that the intended change happened
    • Convincing themselves that only the intended change happened
  • The entire system is unable to be reasoned about
    • Configuration is not treated as code or tested. Meaning “configuration as code” is really just “running untested/unmanaged code in production”
    • Interactions between services are non-local and can’t be easily observed. Even “not distributed” systems are distributed systems now
  • Security and Data Integrity is impossible to reason about at scale, despite being the most critical factor to the success of a business
  • Software Infrastructure and Tech, and RandD are the next big investments.