Developer's Fantasies

The moment I became a proud father I almost lost all of my free time. Since then I became a proud father two times more. To make a long story short – I have three kids. This basically means 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, teach high school kids math, open my own pizzeria and much more. Even when I do find free time I do not spend it on my fantasies because there is simply no point perusing any of them if I have no plan to stick with it.

As a software developer we also have fantasies (job related - other fantasies are out of scope). Each of us has his own ideas about a great change which will defiantly bring improvement. Those ideas are not realized because they have no economical direct incentive. Such ideas range from developing a smart text box which will use natural processing language and understands user requests to replacing our existing old annoying build technology with a new cool one. However, no one asked for a smart text box and the old annoying build system works just fine.

What happens to these fantasies in the agile era? Agile development teaches us to pursue costumer value. Tasks are wrapped as user stories to ensure there is no waste. Said stories are prioritized by value so at all time we work on the most important and valuable story. Technical debt and technical user stories are dealt 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 entertain us or keep us up to date. 

The problem is that besides the fact that it killed some of the 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 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 bad solution (minimum locality). In such scenario the algorithm will not perform well and eventually return something close to the initial solution. How do we escape such minimum locality? One suggestion is once in a while to change your solution randomly without using your brain and smart assumptions. The idea is that sometimes such a bounce will upgrade your solution so well that it will compensate 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 will stick to it long enough we will eventually find better solutions for our problems. One thing we can promise. It will be much more fun.