Agile FUD

Why do some people argue as though "agile" is some grand methodology, a prescribed process, comes with a big book and a two week training course and has a rigid set of mantras? It doesn't as best I can tell. I have adopted some agile practices in my daily routine, such as unit testing (though not TDD as of now), intensive refactoring, simple and frequent communication and continuous integration. There are a lot of agile practices that I do not have the expertise to try right now, or the right projects to try them on or the right team to try them with. I am basically fitting what I can into my current environment, reading all I can and reexamining every month or so to identify what else I can apply or do differently.

I think this is the whole point of agile. That is, there is no one prescribed way. Rather, there are principles or fundamentals, and the practices reflect these in a sort of toolbox approach. And above all, the personnel involved are intelligent and experienced enough to use these things to improve how they create software and in turn improve the software they create.

For example, sometimes we have projects that are remediation types of engagements. In other words, we are hired to fix something and it may last for a month. Can I do TDD? Should I set up a continuous integration server? It depends. I have enough experience to know which tools to apply to solve this problem.

So when I read something like this that portrays agile as some all-or-nothing "methodology," it makes me wonder first, if people like this are using some prescribed methodology already or instead have none whatsoever, and second, if they aren't just looking for a way to bash these ideas by portraying them as something they are not. That post at secretgeek makes it sound as though agile is loaded with ideas that contradict each other. I don't think this is the gist at all.

One tool from the toolbox that has had a huge impact on how I write code is designing for testability. This is one of the first things I consider when creating any code. It forces me to think about:

• How to structure the solution in Visual Studio .NET. I always create a ".Tests" project in addition to the main project (it used to be ".Test" until one of the versions of the Test Driven .NET add-in for VS.NET caused problems in projects named this way). Instead of creating some goofy form to drive my tests and therefore requiring me to manually test each time I make changes, all of my public methods can be launched through my unit tests. Right-click, Run Tests. Low stress. This is pretty standard stuff.
  
• How to design a class. When thinking about how to test it, you must immediately consider what the constructor does, how to initialize state, whether a static class is a good idea for the scenario, etc. Having to change these things later puts you into a much more defensive mentality, where you feel like you are constantly catching up and rethinking very basic design decisions. Again, pretty standard. Thinking about testing forces better design decisions.
  
• How to design its interface. When you know how your class can be used (i.e., because you thought about "exercising" it with unit tests at the outset), your interfaces are much cleaner and more consistent throughout a project.
  
• How and where to initialize and destroy resources. Basic stuff, but again, having to tweak things later can be annoying, and being inconsistent has subtle implications for robustness.
  
• Where to stash configuration information so that it is accessible in a very flexible way. Does the class need a SqlConnection? How do you provide it? Do you have different databases for development, testing, staging, performance testing and production? Instead of cluttering the class with code that accepts these, is it better to make it config-based? If you do, your ".Tests" project needs to be defined a certain way with its own config file, etc...
• How NUnit can automatically run my unit tests to help me control regression. Now that you've thought through these other things, everything is set up to do this. You can make changes and perform major refactoring at will and know what the health of your application is.

The principle here is that these things enable me to set up my project to accommodate change and ensure quality is built in from the start of the project. That's the fundamental requirement to doing these things.

Pretty standard stuff. I am amazed that it's still not universal.