Agile Value #4: Change is good!

Think of change as the result of learning new things. When your customer suddenly changes his mind, the natural reaction is to get defensive and avoid it. But this is in fact a good thing. It means that she has learned more about her problem and has found better ways to achieve her business goals.

So change is good, but to be able to keep up with the never ending flow of changes our software must be built to manage it as easily as possible. This means we should write the simplest possible software which solves the needs of today, rather than guessing about the future. It gives us less baggage to carry around and fever things to change once the future becomes todays reality.

The fourth and final value of the core agile statements brings this piece of advice to the table:

We value responding to change over following a plan

This means you should trust in yourself that you don't know everything today, and that you should only focus on what is most valuable at this moment in time. Or maybe humility to have the insight that you cannot predict the future.

Requirements are decisions about the future. As the future is in flux, so are decisions about it. We probably know enough to plan a couple of weeks, maybe a month ahead, but that's it. Anything more than that is bordering on arrogance in my opinion. When new information comes to light, we should revise our requirements (decisions) accordingly.

One problem is that developers are trained to write software that are flexible, extendible and "future-proof". This means writing code that aren't even used. Let me give you an example:

Create a piece of software that allows the upload of an image file (jpeg) and convert it to a pdf. Easy enough. I'm sure lots of us tries to think a little bit ahead and add support for more stuff. Say, converting png and bmp files as well. Maybe creating a small framework for plugging in new file formats. Sounds nice and fun, right? Writing frameworks are cool and thinking ahead is indeed satisfactory. So this small task grows and the end result is that you spend more time than you really needed. We deliver and the system works.

Now the crucial moment: If we predicted correctly and it turns out we need support for other file formats, you only need to add some small amount of code for that and we are all set. That is the happy future. What most likely happens is that the system doesn't need support for more formats, and the end result is wasted development time. Time that could have been spent on more important things.

I've personally gone down that road several times, and each time have my predictions been wrong. The agile approach is to just build the system as needed today. This is hard for any programmer to getting used to. It takes lots of training and unlearning. A way to think about it is:

How can I write this as simple as possible while still solving the problem at hand and nothing else?

If the need arises in the future, then spend the time to make it more flexible. Since the code is simple, changing it is also simple.