allan's blog - Agile, Lean, Patterns: Things to do to improve code quality

allan's blog - Agile, Lean, Patterns: Things to do to improve code quality

Test Driven Development: if there is one practice above all others which contributes to better code quality and fewer bugs it is TDD. On the plus side it can be used on any type of project, Agile, Waterfall or other. Its roots go back a long way but it was a forgotten practice until XP resurrected it. When run as part of a continuous integration cycle with frequent automated builds and tests the practice is Unit Testing on steroids.

However it doesn't just happen by mandating it so. Most developers don't know how to do it, they need training and help (coaching) to do it. Even then it is going to be a learning experience, don't expect it to become prevalent overnight.

(And before you say "But we have a legacy system with 1 million lines of code so it won't work for us" please read my implications of the power law.)

Acceptance Test Driven Development (ATDD) is the next level up from unit test based TDD. Here those making the requests for development not only specify their acceptance criteria but do so before any development happens, and do so in a way that they can be automatically executed. In many cases professional Testers need to work with the "Customers" to create such tests.

Continuos Integration (CI): This is a valuable practices on its own - making sure code builds and new code doesn't break anything that already exists. When coupled with TDD and ATDD to created automated, repeatable, test suites, it is an order of magnitude more valuable.

Pair Programming: The controversy over pair programming seems to have died down, but then so too have examples of people actually doing it. A shame really. It is instant code review, it is two-heads better than one (think of commercial pilots or surgical teams). It also allows developers to focus intensely on the work in hand - few distractions from telephone calls, e-mails, SMS, and all the other rubbish that distracts us so easily.

Code review: The next best thing to pair programming. If people won't pair then at least code review. Put in place a light weight process which happens as soon after the code is written as possible. The big formal process so many of us learnt about in school aren't practical - only NASA can really afford them anyway. Instead use a lightweight process, you will get 80% of the benefit for 20% of the cost.

Static analysis tools: in the past static analysis tools have gotten a bad name for themselves. The current generation are a lot better and while they are not a true substitute for a code review (because in a code review both reviewer and reviewee learn) they are very cheap to use. Sure you might have to buy a license but once you've done that and set them up in the build system they run every time code is checked in and can highlight potential issues very quickly.

Coding standards: Traditionally I'm not a fan of coding standards. In my experience too many teams waste to much time debating and arguing over coding standards and when they are put in place they can be used as a tool for some developers to bully others. However, if you can overcome those problems then they have a valuable contribution to make.

Read full article from allan's blog - Agile, Lean, Patterns: Things to do to improve code quality