A Good Way For Non-programmer Managers To Improve Quality-of-code

The problem explained here is very common for distributed teams, where the product is created for , not for the team itself. Being a customer in such a project, how do you monitor and control the without programming skills? If the answer is "I trust my programmers" you may suffer from some of the following problems:

1. You are afraid to change key programmers since each of them possesses some unique knowledge about your product;

2. You can only hope that your code is of good quality because your coders say it is;

3. You can't add new features freely since the product becomes unstable after every new change;

4. You feel that if you want to get higher quality-of-code you have to change programmers.

These problems occur in many projects where the quality-of-code is not controlled and is not managed. A common assumption is that good programmers produce good code and if you want to improve the code you should hire better programmers. This assumption is wrong. Quality-of-code in your product has to be controlled by you and now we will show you how to accomplish this.

What are your objectives?

Programmers (coders, testers, analysts) are technical specialists whose motivation is based on . Either you recognize them as "gurus" or their colleagues give them respect for their knowledge or experience, it is better if they receive both. Unfortunately, in most cases money is not the first priority for them.

In order to earn and retain the status of "guru" a programmer has to do something that no one else can do. He or she must know the tricks in your software. After all, the more complex the software is the higher their salary will be.

However, your objectives are different. Your business value is , and you want to invest into it, not into programmers. You want to control it and you want to know that the product really belongs to you, not to the people who know the tricks.

As you see, your objectives and your coders' objectives are not aligned, in other words you work against each other.

Quality-of-code could be measured

To align objectives and start sharing common goals, it is necessary to invent a that will represent your objective and at the same time will impact the programmers' motivation. The higher the metric, the better the quality-of-code will be. At the same time, the benefits for programmers will be higher, like salary and recognition.

We use two metrics: Code Coverage and Cyclomatic Complexity. Each of them are calculated automatically at each round of continuous integration.

tells you that the code is clear and simple and could be easily understood by new programmers (This means no more "tricks"). Cyclomatic complexity is one of the most important software metrics used in static code analysis.

tells you that for each block of code there exists a unit test that validates it. The biggest benefit of unit tests is that once the code is tested it stays workable when its author forgets how it works.

In our management panel you get a graph that indicates current value of the metric and a history of change, like you see in the sample below:

This graph is available for you and your coders. It is instantly updated by our software according to the source code from SVN repository.

How we do this technically

There are five components of the whole process: SVN, Continuum, Maven2, Gist and thePanel. Coders as usualy commit their changes to SVN, and you monitor quality-of-code in our online project management system (thePanel):

The cycle is repeated every day and is initiated by Continuum, an open-source continuous integration software by Apache Group:

1. Coders commit changes to the SVN repository
2. Continuum checks out the changes and starts the builder (Maven2)
3. Maven2 compiles the code and runs unit tests
4. JUnit-like framework produces a code coverage report
5. A language-specific tool calculates cyclomatic complexity
6. The transmitter (Gist) sends XML report to thePanel
7. thePanel converts metrics into bonuses, for coders
8. You get the quality-of-code instantly

This process is absolutely transparent for you and the coders. Everything below the dotted red line in the diagram above is not visible to anyone. Coders commit changes to SVN together with unit tests and get feedback in form of bonuses. You monitor the values of metrics.

We use our own simple cyclomatic complexity calculator based on Thomas McCabe's principles. Code coverage is calculated by JUnit, phpUnit (in combination with xdebug), NUnit or CPPUnit.

What are the pros and cons?

This approach aligns the objectives of you and your coders and returns control of quality-of-code to your hands. You get these benefits:

• Code is always fully covered by unit tests
• Code is clear and simple
• No more "indispensable" programmers
• The more you spend, the better the product

Your programmers also get these benefits:

• Higher motivation because of a clear numeric objective
• More confidence in code stability, less stress

The only disadvantage we experienced after implementation of this method was the necessity to spend time explaining this new approach to programmers, 2-4 weeks at most.

We may be able to help you with your current projects. Contact us today about how our innovative methods of project management can give you a new level of control over the success of your business. Talk to us to see how we can enable success in your project.