In my first development job, a full compile of the software took several hours on the 286 I was working on. It meant that I had to remember not to accidentally type “nmake all” or I would waste a whole morning waiting for the thing to finish recompiling. These days of course, even vast sprawling codebases can be fully compiled in a couple of minutes at most. And we have come to expect that our IDE will give us red squiggly underlinings revealing compile errors before we even save, let alone compile.

This kind of fast feedback is invaluable for rapid development. I want to know about problems with my code as soon as possible, ideally while I am still typing the code in. The feedback doesn’t just need to be fast, it must be automatic (I shouldn’t have to explicitly ask for it), and in your face (really hard to ignore).

Unit Testing

Unit tests themselves are a form of fast feedback compared with a manual test cycle. But when I got started with unit tests, running them was a manual process. I had to remember to run the tests before checking in. If I forgot, nothing happened, because the build machine wasn’t running them. And the longer you go without running your tests, the more of them break over time until you end up with test suite that is no use to anyone anymore.

The first step towards automatic fast feedback is to get the build machine running your unit tests and failing the build if they fail. (And that build of course should be automatically triggered by checking in). Fear of breaking the build will prompt most developers to run the tests before checking in. But we can go better than this. Running tests should not be something that you have to remember to do, or wait for the build machine to do. They should be run on every local build, giving you much faster feedback that something is broken. In fact, tools like NCrunch take this a step further, running the tests even before you save your code for the ultimate in rapid feedback (it even includes code coverage and performance information).

Coding Standards & Metrics

As well as checking your code compiles and runs, it is also good to get feedback on the quality of your code. Does it apply to appropriate coding standards, such as using the right naming conventions, or avoiding common pitfalls? Is it over complicated, with methods too long and types too big? Are you using a foreach statement where a simple LINQ statement would suffice? Traditionally, this type of thing is left to a code review to be picked up. Once again the feedback cycle is too long, and by the time a problem is identified it may be considered too late to respond to i.

There are a number of tools that can automate parts of the code review process. Often these are run after the build process. Tools like FxCop (now integrated into Visual Studio) and NDepend can spot all kinds violations of coding guidelines, or over-complex code. The feedback must be hard to ignore though. I’ve found that simply running these tools doesn’t make people take notice of their output. Really, the build should break when problems are discovered with these tools, making their findings impossible to ignore.

Even better would be to review your code as you are working. I’ve been trying out ReSharper recently, and I’m impressed. It makes problems with your code very obvious while you are developing. It’s a bit of a shame that it doesn’t seem to have built in checks for high cyclomatic complexity or methods too long, although I’d imagine there is a plugin for that somewhere.

Obviously there is still a place for manual code reviews, and tools that run on the build machine, but anything that can be validated while I am in the process of coding should be. Don’t make me wait to find out what’s wrong with my code if I can know now.

UI Development

Another aspect of coding in which I want the fastest possible feedback is in UI development. That’s why we have tools like the XAML designer in Visual Studio that previews what you are making while you edit the XAML. I wonder whether even this could be taken further, with a live instance of the object you are designing running, with the ability to data bind it to any custom data on the fly. 

Conclusion

We’re seeing a lot of progress in developer tools that give you fast and automatic feedback, but I think there is still plenty of room for further innovation in this area. It is well known that the closer to development bugs are found, the quicker they are to fix. The logical implication of that is that we will go fastest when our development IDEs verify as much as is possible while we still typing the code.

I'd be interested to hear your thoughts on additional types of feedback we could get our IDE’s to give us while we are in the process of coding.