The moment I became a proud father I lost most of my free time. Since then, I became a proud father of two more children. So with three kids, I have almost no free time at all. Every now and then when I have five minutes to think clearly I fantasize about things I would have done if only I got the time. This includes learning how to play the guitar, teaching high school kids math, and opening my own pizzeria. Even when I do find free time, spending it on fullfilling these fantasies would be pointless if I have no plan to stick with it.
As software developers, we also have fantasies—developer fantasies (job related - other fantasies are out of scope). We each have our own ideas about how to bring great change to the field of development and, in turn, great improvement. Many of those ideas never blossom because they have no direct economic incentive. Such ideas range from developing a smart text box that will use natural processing language and will understand user requests, to replacing our existing old annoyingly built technologies with cooler ones. Most likely, though, no one asked for a smart text box and the old system work just fine.
What happens to these fantasies in the agile era? Agile development teaches us to pursue customer value. Tasks are wrapped as user stories to ensure there is no waste. Said stories are prioritized by value so at all times we work on the most important and valuable ones. Technical debt and technical user stories are handled with extra care. We only work on the most painful ones. We have been taught to adopt a new technology only if it helps us solve a problem, not if it entertains us or keeps us up to date.
The problem is that regardless of the lost fun in development, it also keeps our solutions close to where we found them.
Several algorithms in computer science such as the Genetic Algorithm and the Simulated Annealing Algorithm use randomization in order to escape minimum locality. In a nutshell, these algorithms are based on the following methodology: They start with an initial solution to the problem. Then, iteratively, they use 'smart' assumptions to improve the solution by making small modifications to it. The more iterations they undergo the better the solution they will find. The problem with this approach is that the initial solution might be surrounded with a bad solution (minimum locality). In such a scenario the algorithm will perform poorly and eventually return something close to the initial solution. How do we escape such a minimum locality? One suggestion is to occasionally change your solution randomly without using your brain and smart assumptions. The idea is that sometimes such a bounce will upgrade your solution enough that it compensates for other times where it did not help at all.
How can we escape minimum locality in our development process? Even in the agile era we should spend some time on our fantasies. Such random bounces in our iteration should be integrated in the agile methodology. If we stick to it long enough, we will eventually find better solutions for our problems. One thing is promised. It will be much more fun.