Got your back...

Peter Varhol has posted a blog entitled Got Your Back, and in it, he talks about ways to ensure stable code, by essentially knowing how to use tools. His examples note code reviews, unit tests, and exception handling in the list of tools, but I would also add in logging in this list, since when you log sufficient information, it can be used to also see situations and bugs that would be extremely harder using other methods.

All of these tools are essentially insurance for your software, which could contain anything from a simple one line bug or a complex architectural problem. The aforementioned tools will attempt to exercise your software in ways to expose these conditions. Of course, this means that you really have to include code reviews in your process, and to actually attempt to break code when creating test suites and run such automated tests regularly. This means that you have to use language features to make your productivity higher, and that you need to actually log information in an accessible and usable fashion.

At present, you need people to ensure that these things happen, and this comes back to the broken window theory. If a developer is used to strict coding standards, and is then exposed to a group with no coding standard, chances are that his own code will get slightly sloppier, simply out of the case that there is no authority to curve this. But such examples are an over abundance in business, as discussed in books such as Database Systems Management and Design.

There is, however, no question that such behaviours are time consuming, and as such, it would be great to automate these to take some burden off the people involved in a project, but as Peter says, we are not there yet, and I think we are far off. Modern IDE's have been improving significantly over the years, and movements into this direction are highlighted by Borland's integration of their Caliber requirements management application into their IDE's. And while this does seem that it would allow for tracking of software features from inception to delivery, I suspect that such products will suffer from how they are used and maintaining that ever important shared vision. Specifically, if the tools are not properly integrated, I see developers using them in vastly different ways, and while this flexibility is good for some aspects, this flexibility could harm the usability of feature tracking. But also such tools will still require human intervention for many years to come, as they will not really be able to decide the completeness of a feature alone, let alone whether the implementation accurately reflects the desires of the user.

Until we are presented with software that can think for itself, there is no way to get rid of people completely, but by using unit tests, language features, and logging coupled with code reviews, quality software can be not only developed, but maintained.