09 July 2008

Building code quality into the culture of a development team.

Comments (0)

I like to build code quality in the culture of development team. Being proud of the code quality is something that I want my developers to aspire to. I actively manage towards this by focusing on shipping high quality production code; not on technical issues [I'm pretty agnostic when it comes to technology].

The three management tools I use to achieve this are:

1. Agile development methodologies
2. Building code quality into programmer KPIs
3. Make programmer KPI measurements public

Agile Development Methodologies

By this I mean:

• Small milestones of production quality code & all stakeholders having visibility of project progress
• Programmer commits own tests with code
• At least a daily build, or preferably a build with every commit & the team is notified of a commit that breaks the build; ie: cruisecontrol 
• Daily team meetings [ie:scrum] that update on progress

Stake holders should be able to see an up to date view of project progress & quality. Issues should be identified early & remedial action can be taken before a small issue becomes a large issue.

I like to have a stated code testing/quality assurance strategy. With Tickex, we had commercial pressures to ship code very fast, & change often so I settled up on the follow [its tailored for a Ruby on Rails project]:

• Standardise environments [development, test, stage, production]. Developers can use their preferred tools, but commited code must work on the standardised environment.
• Aim for 100% Rspec Model coverage
• Cruisecontrol runs tests on every commit & notifies team if build is broken
• Utilise Selenium for user land testing, rather than testing controller actions.
• Performance testing using Hpricot & Selenium Grid -  - to script concurrent user sessions
• Manual tests for muliple browsers [ok as long as the feature set is not massive]

This is a balances providing the high level of testing coverage with the ability to rapidly turn around features. As a result of this, we have experienced zero downtime from code issues, and very few bugs have made it into production [& most of those have been specification issues, rather than code].

Build Code Quality into Programmer KPIs
Every environment is different, but here are some guidelines. Each metric on its own is pretty much worthless, but the whole will build a picture.

Quantative KPIs

• lines of code
• milestones met or features delivered
• bugs in code
• number of times commits break build

Note: lines of code is a bit controversial as on its own its a pretty meaningless measure [a good programmer will do something in many lines less than a bad programmer, but will also complete more features]. I have a couple of MBA type CEO's who have really struggled with this. Patterns should be investigated though.

Qualitative KPIs

• Peer reviews - both quality of code & as a team member
• Customer/Stakeholder feedback - satisfaction with work
• Test coverage of code
• Team fit

Make programmer KPI measurements public
Making these measure available public, on a wiki, & in regular team meetings is intended to build a team spirit. Peer pressure can be a better motivator than agressive management.

I don't favour an agressive leadership style. Fear is one motivitor,but I don't believe it leads to habits being formed & long term behaviourial change. I think that respect of a manager & peer pressure lead to long lasting habits being formed. This is not to say be a push over, think hard but fair; If someone is not performing, I put the ownus upon the team to sort the issue quickly, then act accordingly and decisively if needed. The message will be seen that code quality cannot be compromised.

This philosophy is independent of team size or technology. Whether a small ruby/php team or a large .Net or Java team it does not matter to me. What matters is predictably shipping high quality production code that meets customer requirements.