Agile Development, another misunderstood buzzword

Agile development is something of a growing software culture. Every dev team is trying to become agile. Programmers I know working like that are all happy and evangelizing the concept as the best thing since the fire simulation algorithm. The word is that Agile gives control back to the developer.

So, what does a code monkey have to do to become agile? (and no tree algorithm jokes here, please!). As experience dictates, Google for "become Agile in 11 seconds" and see what tools one can download and integrate in the personal toolbox! Surprise! There are tools, but they only help you when you are already agile. WTF? It was supposed to be a developer empowering thing!

Actually, this has an only marginal connection to the developer. Agile development is actually a management strategy. No programmer can become agile without the support of their manager. Management in itself is the application of scientific methods to achieve business goals, which are, almost every time, to maximize profits. You see, managers have noticed that they could hardly quantify programmer work. Software development was becoming more artsy and less scientific as technology grew ever faster and more complex.

The typical development cycle of a piece of software is to plan it (sort of) do stuff to it depending on the planning (which always results in changing the original plan or ignoring it altogether), then show it to the customer. They will, almost every time, just applaud and ask you "ok, this is nice (albeit full of bugs), but where is what I wanted?". The manager then gets scolded for not doing their job. But how could one possibly know what the client dreamed of when they said something completely different at the start?

So, what does a manager do when they have a big problem they can't get their hands on? They split it in smaller problems! Divide et Impera! said the Latin managers of old. So the Agile solution was to copy the development process in its entirety, make it as small as possible, then repeat it until it reaches the original size. It's like when you kill the monster at the boss level and he splits in many small bosses (let's call them middle managers) that you have to kill individually to continue the game. Hopefully I have explained this in a way most code monkeys would understand :).

What about empowering the developer? It was a really nice side effect, one that was taken into consideration at the beginning, of course, but I am sure exceeded the expectations of the designers of the process. You see, at the end of each iteration the application should work, somehow, and also be tested, documented, code reviewed and client approved. The client will undoubtedly notice a discrepancy between what he wanted and what was produced, but he can give feedback a lot sooner than at the end of the project. The developer doesn't have to work their ass off to finish the product, sometimes ignoring the most basic testing or documenting techniques in favour of speed, and then be forced to start work almost from scratch because the client either changed his mind or was not understood properly. Therefore there is an increase in motivation and thus productivity and a decrease in unnecessary work. This is also incorporated in one the agile principles YAGNI, which is actually a really buzzy and ugly acronym for "you aren't gonna need it" - in other words, do the least work to achieve the exact desired result.

But most importantly, this is a managerial process, one that is now easy to analyse and even quantify (since the idea to do as much automated testing as possible). If the bugs are too numerous, then testing must be improved. If code is too obscure, code review and refactoring must be done. If nobody knows how to use the product, documentation is needed. But only for the last small bit that was done. Even more cool, the documentation, code review and even refactoring can be done on the code from the previous iteration, while coders are working on the current one!

So, to summarize: to be agile means that your management has decided on a new strategy and you understand the principles enough to get the tools that would make it easier to work under them as well as design your applications to neatly mold to the concept. It does NOT mean you get some library or development tool and it does things for you. There is not an agilizer application (yet? :) take a look at Pex) and the different software patterns like MVC or MVP are used to facilitate the technical solution found to solve the managerial problem of quantifying results (in this case quality) which is Unit Testing.

It's not that Agile Development is not a good idea. Managers don't really see eye to eye with programmers because they have completely different goals - managers see things from the business perspective while developers see it from the beauty and functionality of code. It's like physicists and mathematicians all over again - but both are (or should be) scientific types that try to solve problems in the best possible way. Agile is a happy intersection of their goals, but as it happens, must be implemented in both worlds simultaneously.