Tick-the-Code for a Chief Technical Officer (CTO)

Tick-the-Code is a practical way to improve software quality. It has gone through extensive research. 350 software developers from 15 different companies in four different countries were studied for the following results:

Developers find many times more

The experiment ran as follows: Developers searched for problems in their code for 15 minutes, the number of findings was recorded and multiplied by 4 to get an estimate of how many items they would have found in an hour on their own. Then they were taught Tick-the-Code and asked to check the same source code again, this time for a full hour.

The results are shown in Figure 1. Each checker has two data points, one in the "before" line showing how many items he would have found in an hour on his own (probably an overestimate) and one point in the "after" line showing the actual number of items he found with Tick-the-Code.

The average improvement was 5-fold!

The code the checkers ticked was real production code, which had gone through all the normal quality assurance procedures until then. The number of findings is just amazing and the improvement shows how much potential there is in software developers.

With Tick-the-Code you find items fast

Table 1. collects the results of 307 software developers, who participated in Tick-the-Code training sessions around the world in 2006-07. There were three slightly different experiments done, and they have been summarized in three separate tables. In each table there is the number of participants, the total time used for checking (the sum over all participants), the total number of lines of code ticked (the sum over all participants), the total number of ticks found (sum over all participants), and the average rate of finding a tick over all participants.

What should be evident from the tables is that you can cover a lot of code within a fairly short time. Each participant had about 1000 lines of code to tick, and not more than an hour to perform the ticking. Tick-the-Code is truly efficient.

Another important fact is the number of ticks found. The participants had never before ticked code, yet they managed to find dozens and dozens of improvement possibilities in code that had already been through the 'normal' quality assurance processes. Tick-the-Code is truly effective. If you look at the speed the participants found the ticks, you can see how systematic and focused the searching is. These are beginners, trying out a completely new method for the first time on real production code and they find more than one improvement opportunity every minute for an hour! Do you know of any other method that does the same? You could argue that static analysis tools do similar feats, but here we are talking about developers reading the code and getting a detailed picture of it.

The fact that the developers found so many ticks in such a short time, could of course mean that the code was bad. Unfortunately it turns out to be quite average-level code in the software industry. The participants in the three experiments come namely from several different companies, are located in several countries and work in widely differing application areas. They have nothing in common, other than a tendency to create unnecessarily complex code and not having a way to get rid of it afterwards.

Tick-the-Code is a measure of complexity

Thomas McCabe created a measure of complexity in his paper 1975. He described the program flow as a graph with vertices and edges. He then went on to define a formula for counting the complexity of the graph (and the program) and called it 'cyclomatic number'. Without going to the details here (Entry in Wikipedia), the bigger the cyclomatic number the more complex the source code is.

Figure 2. shows an experiment on some open source modules. Tools from Testwell Ltd. were used to calculate the cyclomatic number for the files. The module files were ticked with all 24 rules of Tick-the-Code. The figure shows a strong correlation (0.7) between cyclomatic number and the tick counts.

The 24 rules can be divided into 4 categories:

• Risky assumptions
• Chaos-inducers
• Missing info
• Extra baggage

All the categories have a strong correlation with cyclomatic number. This could mean that all the rule categories track complexity like cyclomatic number does. No matter which rule you break in your code, you are unnecessarily adding complexity to it. It means that you can use the tick counts to rank the source code module in the order of complexity. That way you can target your quality improvement efforts to the modules in real need of them.

Conclusion

As you can see, the evidence speaks for Tick-the-Code. If you need to improve the productivity of the software development, Tick-the-Code is an excellent candidate. You give your developers many times more improvement opportunities that before, they won't have to spend too much time in ticking to reap the benefits and you can see the improving quality in declining complexity.

When code becomes simpler and more understandable, you start seeing savings in less and less rework. Productivity increases as rework decreases. What is finished stays finished (and doesn't come back to haunt you).

Make a safe bet, introduce Tick-the-Code to your software developers. Eliminate errors, enjoy the effectiveness, evidenced by empirical experiments, elate for efficiency. Tick-the-Code!