Agile Tools

I get asked about what tools we use every once in a while. Last week, someone said: 'Surely, this command-line stuff is not what you're using normally. You are using some kind of IDE, right?'. Nope. IDE. Huh? OK let's take a step back.

Tools are there to support your goals. If your goal is to be able to type, compile and run as fast as possible, then an IDE may be your best bet. Mine happens to be to produce the best software possible given the constraints. Constraints like time available, the interests of the programmer, the wishes of the users, and lots more.

One constraint is a high 'manageability'. For that, it is important to know exactly what the role of every piece of software is. And the dependencies on other parts. The role of all sorts of tools that claim to support 'Agile' must be to increase the quality of the agile process. As far as I can see, routinely working in IDE's does not reach that goal. Why not? Because for one you are not forced to think about your dependencies. Everything is always available, everywhere. Another serious problem is that quick compile&run doesn't invite to thoroughly think about the logic; rather, it invites 'run and see what happens'. Which is disastrous for quality.

On a higher level, there are the 'Unified' methods. This is basically old stuff in a new form, trying to alleviate the consequences of top-down schemes. The funny thing is that they do all have the same concept behind it: Think on the high level, (almost) generate the low level. Which looks much like ... Waterfall revisited. A prime lesson of Agile is that everything from requirements to high-level design to implementation details is coupled. You can say you want the one-button 'Find oil' application, but the implementation details are simply proving that your requirements are wrong.

What you need to do is consider everything at any time. So you need tools to help you get insight: They generate designs from code rather than the other way round. And they are very 'free-form'. An important tool for us is Wiki. With this you can state initial ideas, order them to make estimates, collect examples, etc. etc (see - for example - the No specs? post). It is ideal to have clients cooperate even if the only thing they do is read it and make comments.

Procedures and communication are much more important than tools. For example, I can say that a debugger is a very important tool. Every developer should be extremely comfortable with a good debugger. Nobody should deliver anything that hasn't gone through debugger runs, where you simply inspect all your constructs to see whether everything is exactly as you expect and intend it to be. Thus, if you want to, you can state the procedure as: 'never just let it run and see what happens'. This is much more important than the tool, as there are other things that complement debuggers: dump facilities, debug modes, ...