Technical Risk

  • Software people love to debate the value of software timelines/project deadlines123. I think this hand-wringing arises from an incomplete understanding of how deadlines get missed.
  • Deadlines are really a problem when software projects are harder than you thought they’d be. Emphasis on “than you thought” rather than on “harder”.
  • Not knowing how hard a technical project is, is the definition of technical risk
  • Technical risk and difficulty are totally orthogonal. Digitizing forms is high-difficulty, low-risk. “I think there’s an API for that” is low-difficulty, high-risk
  • Risk depends on both the nature of the project and the knowledge of the developer. Everything is higher-risk for new teammates who don’t know the tech stack well, and it’s highest risk for new devs who don’t know any analogous tech stacks
  • A challenging corollary of this is that only the implementing developer knows how risky a project is, because only they know what they don’t know.
  • Another corollary is that senior engineers can provide a huge amount of value just by de-risking others’ projects with the knowledge they passively hold (by estimating whether an approach will work and answering questions as the work progresses).
  • There are lots of techniques for managing/mitigating technical risk: spikes (for the risks you know about), MVPs (or, my favorite game: what would it take to get this done in T/2, which forces you to reflect on what you know will work vs. what you hope will work)

  1. https://jproco.medium.com/how-to-deliver-software-without-deadlines-872f8eb244b0 ↩︎

  2. https://www.freecodecamp.org/news/how-to-make-peace-with-deadlines-in-software-development-6cfe3e993f51/ ↩︎

  3. https://www.quora.com/Is-missing-deadlines-common-in-software-development ↩︎

2022-09-30