Building great software is hard. It starts with the choices you make and making great choices is really hard. After all, given the choice, we’d all choose to make great software right? So what’s the catch?
Picture a young guy out to buy a car. He really wants a convertible, it really fits with what he wants out of life right now. So he buys a convertible. He meets a girl, settles down, and before you know it, a baby is on the way. Now the convertible isn’t so great. What helped him when he was dating isn’t much help to him now. Now he wants a saloon!
Our current choices often conflict with future circumstances, however, if we focus too heavily on the future, we may actually make decisions which conflict with the present. A decision which is great for the future might be terrible news right now and vice versa. So how do we deal with this conflict? As it turns out, we tend to deal with it rather badly.
Decisions go stale. As business needs change, what’s relevant today is no longer useful in the future. In software development this means each feature will at some point fail to be relevant. Developers can see this as a failure to make the right choice rather than accept that ultimately our decisions will at some point be irrelevant. It’s likely that given such failure there will be the belief that enough learning took place to make a better decision in the future. We completely ignore the fact that at some point those choices will also become stale. Rather than turn our attention to being good at handling change, we repeat the cycle of trying to improve our decision making process on the basis that we’ve learnt enough that it won’t happen again. We naively think that next time our decisions will stand the test of time!
In extreme cases decisions can go stale before we’ve even acted on them. Businesses don’t wait for you to finish, they continue to change and learn. Being mechanically minded, let’s say we decide to build a saloon. This will take some time. While we’re doing this our child could grow up, leave home and we’re left wishing we’d built a convertible.
The conflict between present and future choices creates a problem in defining a successful software project. Success or failure at this level is outside our control: we can’t predict the future so we don’t know how relevant our choices are going to be over time.
In order to handle this conflict, we have to make it a non-issue. We have to be successful at adapting to change. What really matters to our success or failure is our ability or inability to respond quickly to change. When we can’t adapt quickly to changes, such as new or revised requirements, we have ultimately failed to manage the conflict. The good news is, if we understand that we have failed to respond quickly, we can invest time in understanding why that is and learn from this failure in order to improve our software development process to better handle change.
For a software team to be successful at adapting to change, you need to understand that you’re biggest asset or liability is your code. No decision you make can ensure your code outlives its usefulness, all you can do is ensure you can change it quickly, easily and without risk. To do this you will need clean, loosely coupled, well structured, unit tested code.
Similarly, business stakeholders need to help break the mind-set that features are perpetual. Software is evolutionary and features carry an amount of speculation about current and future value. Rather than telling developers what the business needs (or developers interpreting needs as perpetual), a “let’s try this next” approach to implementing features helps to reinforce the understanding that change comes with the territory.
Focus on handling change well. Your process should be about improving the ability to handle change by understanding and identifying your failure to respond quickly to change. Loose the ego and stop being frightened to admit failure and maximise the opportunity to learn as much as you can for the next change – it’s definitely coming!