In my observations of many different software development teams I often get an impression that people see time as the most important commodity available. This is reflected in statements like:
- “This project is going to be late”;
- “We are incurring technical debt because we’re going too fast”;
- “If we spend more time planning we can be more confident about the outcomes”;
- “We have defects in production because we didn’t spent enough time testing”.
All these statements suggest that time (that is if we had more of it) could easily be exchanged for other qualities of our software development processes. More time for development can be changed for cleaner code; more time planning – for higher certainty; more time testing – for higher product quality. This is a natural and understandable approach. Many things that we directly experience in the world around us, particularly those that deal with construction or production, appear to have such properties.
In my experience these statements have very limited application to software in particular and more generally to product development. As Kevlin nicely puts it in this great podcast
“because you spend a lot of time pausing trying to understand stuff […] it turns out you actually have plenty of time”
This exposes the true underlying commodity that we should really focus on: learning.
Sure time is required for learning but time on its own is not sufficient. We must expose assumptions, run experiments to verify them and adapt based on the outcomes.