We should know that software development methods are situational, so why do so many people believe one process should work for every project? One size does not fit all and rarely do quick-fix methods help the process fit. In this week's column, Pete McBreen considers why we jump on the latest software development trend and what the fallout is when the trend and the project don't match.
Is Agile development for everyone? The obvious answer to this question is no. If we have learned anything about software development in the past thirty or forty years, it's that all processes are situational. A one-size-fits-all process approach to software development is a recipe for certain failure. What is good for one project is not always good for another.
All too often, new approaches are sold as if they are the best things since sliced bread. Process zealots and evangelists make so much noise about their flavor of the month that even sensible managers and developers are duped into trying out a new idea that instinct tells them is not a fit. A classic example of this is Extreme Programming. This approach grew out of the small-talk community, gained a few true believers, who in turn converted other people. Suddenly books were being written about Extreme Programming; XP immersion courses were available, and international XP conferences were scheduled. Suddenly, XP was the "it" process, and people were clamoring to learn about this cool process and wanting to try it on their next project.
This bandwagon-effect is a great example of what George Soros, founder and chairman of the Open Society Institute, calls a "fertile fallacy," taking a valid idea (having found it useful), and extending it to areas where it does not apply. As humans, we all try to employ our ideas as widely as possible, but inevitably, the ideas do not apply in all instances. The extent and nature of our misunderstandings may vary - Soros calls this the "postulate of radical fallibility." Simply put, we make mistakes all of the time, some small, some big, and some that we can cover up and pretend they never happened - sometimes you feel like the emperor wearing his new clothes.
Extreme Programming is a good choice for some projects. The same is true for the other Agile approaches - some, but not all, projects could benefit from adopting these approaches. My hope is that as other Agile techniques mature, the acknowledgement that these methods are suitable for some projects, but not all, will be made. Without the acceptance of proper applicability, the Agile community is just setting itself up for more fallacies that will result in spectacular project failures. As new software development methods premier and address the perceived problems of the former Agile processes, the risk increases for more ideas to spread beyond the intended reach. This will continue the generation of fertile fallacies perpetuating the boom-bust cycle where new approaches are over hyped and then discredited.
The problem with these boom-bust cycles is that the beneficiaries are also the speculators and consultants. The poor managers, developers, and end-users are left suffering. Yes, they partially brought the troubles onto themselves because they fell for the quick fix offered by the latest craze. Thus, the software development community fails by not learning from past lessons. There is no quick fix. Good software development takes a lot of time, and it is all too easy to fail at software development.
But it is not all doom and gloom. Agile development has restarted the conversation about what it takes to create great software. We are starting to question the processes we use and are again on the path of becoming reflective practitioners of our craft who draw from lessons learned. Above all, Agile development has made software development fun again. After all has been said, our trade is meant to be fun. If it isn't, the process is wrong.
