Lines of Code

Our configuration management team sent me an unusual request. They had identified all the files in our source code control system. They wanted to know which file types can be counted to arrive at a source line of code count. The idea was to tally up the numbers and give a report to our client. Now this task alone was not difficult. Any developer worth his salt knows which files are source files and which are not. Actually the CM guys should be able to figure this out. Does anybody really thing a bitmap (bmp) file contains any source code?

The real concern was why somebody wanted to count the lines of code. Such a metric is not evil in and of itself. But if you do not know what you are doing, you can become dangerous having such a metric at your disposal. Lines of code is a relatively unambiguous metric. Interpreting this metric can be difficult to fathom. For example, you might refactor your code and arrive at a lower count. Somebody looking solely at the count might think that you have then made negative progress toward some development goal. Or you might see that there are 20k SLOC which took 20 months to develop, and assume that a new 1k SLOC change will then take just 1 month to complete. You get the picture.

I do not like to second guess our CM team. They are pretty sharp technical guys. If they have a task to count up the lines of code, then I can support them. I rely on them often to help me out with Rational Clearcase. So I answered their questions regarding source files that should be counted. In the end they came up with a count of 215,000 lines of code in our two largest applications. This seemed to be on the correct order of magnitude. A couple year ago I did a lie of code count using the UNIX wc command. I came up with 270,000 lines of code. My count may have included the source code for some third party tools we were using. So my count may have been artificially high.


Recently my company announced that it was not seeking to achieve a Capability Maturity Model (CMMI) level of 4. Instead we have decided to remain at CMMI level 3. This decision was made at the company level. It does not mean that certain project may not individually aspire to the higher levels. The reasoning behind the decision was the result of a detailed cost benefit analysis. I guess the heavy cost to get to the next level was not expected to be offset by any gains it would produce. My company is very methodical about things like this. They are not afraid to spend money. But it is only done when there is a definite return on investment perceived by the decision makers.

Personally I was happy with this decision. As a developer, I am not really interested in ultra high CMMI certification. Getting to level 4 would have most likely meant that I would have to collect a lot more metrics on a recurring basis. That does not sound like fun. At a deeper level, I doubt it would yield any positive results either. Developers can game the system once they identify how the metrics are being collected. This can only lead to improper results.
It is not that I am against process per se. Process is good if it is applied properly and within moderation. I was surprised to find out that our company had been awarded a level 3 certification anyway. The contract for our current project was recently won. But I do not sense that we are performing at a CMMI level 3 of maturity. There are a number of important processes which are not documented for development. Luckily for me I have been on the project for a long time. But the new guys often have trouble figuring out what to do. I wish there was a document I could point them to in order to explain things are done.

I suspect our project will follow the company lead in remaining at CMMI level 3. Our job should be to correctly document the current processes in place. That would be a good start to improving the process around here. We have some good developers on the team. I am hoping that this will result in a positive development experience. I have been through enough failures to know that nobody likes the pain of a botched project. Our team has ambitious goals for the next year of development on this project. Extra work to collect metrics for a CMMI level 4 certification might put those goals in jeopardy. I will plan to report back in 6 months with how we did.