From Wikipedia, “Kaizen is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life”. After a review of our systems from a software coach in the department, I decided to instigate a weekly Kaizen session for the whole dev team. (I first heard of the term Kaizen a few years ago when my then department manager spoke of it and I guess now I understanding what he was meaning – thanks Marc!)
The plan is to spend 1 to 1.5 hours a week pairing with another dev investigating a certain area of the code trying to improve it with no strict deliverables. The hope is that the tools and techniques we use in these sessions will become integral to our daily work and code quality will measurably improve.
To feed into these sessions I created a backlog of features to be investigated. These were stuck on cards on the whiteboards for the pairs to select from. Anyone is free to submit a card for an area of code they’d like to look at.
Here’s a few of the cards I created for week 1 to start us off.
Method foo has a Cyclomatic Complexity of 28, aim to reduce it.
Using NDepend i’ve been looking at some metrics across one of our projects. NDepend gives you so much data that it’s easy to be overwhelmed so I chose Cyclomatic Complexity. This found a single method in our code rated at 28 – that’s to say, there are 28 paths through that method. Although we have 13 unit tests for this method we aren’t testing every line of code, and there’s probably some refactoring that can be done.
Class foo has test coverage of 72%, aim to increase it.
Using the TestDriven.net Visual Studio plug-in with NCover we monitor code coverage of our unit tests. 72% is great, but quite a lot of our code has over 95% coverage so this class needs more testing.
There are 8 unit tests currently marked as [Ignore], without simply deleting the unit test, aim to reduce that count.
This is pretty self explanatory. I don’t know why the tests were marked with the Ignore attribute, but they are, and they shouldn’t be.
I was shown today how by using the Duplicates.NET build runner in our Team City CI server it can automatically identify duplicate code across the system. Despite the fact that this project was a greenfield development we’ve still ended up with some duplicate code in need of an Extract Method refactor. Metrics from these reports will feed into our Kaizen backlog.
For those interested, the end result of the above 3 cards was 12, 74% and 4 respectively, so i’m happy we’ve improved the code and got familiar with the tool set.