Software Development: It's About Risk

Challenging software developers about how much time they’re taking to build things is a losing battle, especially when you’re non-technical. It’s often non-obvious what takes lots of time and what doesn’t, so the key to an effective relationship with your developer(s) is communcation.

When you talk about what to build next, is there a dialogue between you two? i.e. do you ask how long things will take, and then prioritize based on the ROI? Giving a developer an arbitrary deadline is fraught with peril, but asking a developer to estimate a project is more reasonable as long as you’re understanding when things take longer than estimated. The fundamental nature of software development is that we’re often doing things that haven’t been done before, and so they’re inherently hard to estimate. Is your co-founder giving you timely heads-ups when something looks like it’s going to take longer? Often it makes sense to give up on a project that turns out to be 10x as difficult and switch to something with a higher payoff once you realize how difficult it is.

The best approach I’ve seen to software development is to focus on de-risking: Constantly ask “What is the highest risk part of this project?” and find ways to cut that risk. Risk in software development is generally tied to uncertainty: things you aren’t sure how to build are high-risk. Things you know how to build and how long they will take are low-risk. Often we de-risk components with “spiking,” where you go and start building a component to better understand what it will take. You come back from a spike, which usually lasts 1-2 days, with a clearer understanding, which reduces risk. When you work from highest-risk parts to lowest-risk parts, the final estimate becomes clearer and clearer as the project progresses.