“If you cannot measure it, you cannot manage it.”–Peter Drucker, management consultant
Measurement is an essential step to achieve effective management. People are aware of it and they use metric sets to measure projects. Compared with the elements that are hard to measure like qualitative information, they tend to focus on quantitative information like numeric quantity which can be measured easily. However, easily measured elements might not be as important as or more important than harder ones in terms of its contribution to project evaluation.
This is the same with software development. When we measure a software project, we need to first find a quantifiable metric. A most intuitive answer is to use the code line by line. In fact, lines of code (LOC) are widely used to measure the size of software and sometimes to evaluate the productivity of developers [1]. However, before we use it, we might need a minute to think carefully whether this is a good metric.
Is it an easy thing to count code lines?
If we use LOC to measure our software project, first we need to count how many lines of code are there. It seems that this is quite an easy thing, just by counting the lines of each file or each module. Here, question is how could we count precisely? In a large-scale software project, code is modified as requirement changes or bugs found and it may happen during development stage or even after the project is released. Which pieces of code are written in the development stage? Which pieces are added or deleted when we deal with bugs? People may suggest using simple maths computation to solve this problem: to count how many lines of code are changed, how many lines are newly added and then add them together. But for the “changed code”, we have to notice that it happens because developers add some new functions or modify bugs. So it is difficult to count exactly how many lines of code are there especially for those who are not quite familiar with the project.
Another problem with LOC…
There are several methods to calculate how many lines of code are there, for example, counting executable lines of code, data declarations, lines that are not null, etc. Different corporations or even different teams might not use the same counting rule. It’s meaningless to compare size of the projects or productivity of developers by using LOC when they are calculated on different standards.
Okay, assuming we could count code lines precisely and using the same counting method.
With the precious number of lines, companies could use it to evaluate the productivity of a programmer. Banker and Kauffman put up with a formula to compute the productivity after they did some research on software life cycle productivity [2].
Productivity = (Size of application developed) / (Labour consumed during development)
However, in real life, developers might be working in two projects in the same time; some of them might be responsible for only half or one quarter of the whole project. For these developers, the productivity calculated using the formula mentioned above would be much lower than those who work full time on one project. But we cannot simply come to the conclusion that they have lower productivity compared with others.
Another fact we need to notice is that there are thousands of programming languages. When LOC was first introduced as a metric, the most commonly used languages are FORTRAN, COBOL and Assembly language. For these languages, it is easy to count the lines. Later, high-level languages like JAVA, C++ appeared. In these languages, a single statement generally results in many machine instructions. It means that high-level languages might use fewer lines of code to implement a function. And it is also not meaningful to compare the number of lines of code developed using structured languages versus object oriented techniques [3]. For example, a system could be implemented with 6000 lines of Assembly code or 3000 lines of C++ code. Suppose a developer using assembly language writes 600 lines of code per month while a C++ developer writes 300 lines of code per month. It seems that the former developer has high productivity over the latter one. But when the two developers are developing the project mentioned above, they might finish it using the same amount of time. Advanced programming languages have strong expressive power. The more powerful the language is, the lower productivity it shows for its developers. So we can’t simply decide which developer has higher productivity simply based on these numbers.
What about clients? Is LOC meaningful to them?
Some corporations especially multinational ones would prefer to outsource different parts of the system like designing, coding and testing to different organizations. Clients care about the function [4]. Only the business value brought by these function is meaningful. LOC is not a metric that could be used to evaluate how meaningful the function is. More code does not necessarily suggest that the function is robust or the business value is large. In contrast, it might mean that there is code redundancy in the project. Besides, standard template library, class library, and software development kit like visual programming language are widely used today. As a result, many pieces of code are generated automatically. There also might be automatic configuration script and user profile in the code. As a result, it’s meaningless to measure the projects using LOC.
Conclusion
Every coin has two sides, so is the metrics used in software measurement. On one hand, metrics can be used to control and adjust development processes. On the other hand, developers might pay more attention to the elements that can be easily measured while ignoring the elements that are important but hard or impossible to measure. LOC is a most intuitive metric used in measuring both the size of the project and the productivity of the developers. However, there are several problems with it including LOC is difficult to measure, there is no agreed standard, and LOC is dependent on programming language, etc.
To achieve effective measurement, we should ask ourselves what is the final goal for the project? Is it to implement functions on time and within budget, to deploy the product massively and serve large amount of clients or something else? Based on the answer, we need to think about what metrics should be used to measure part of the project, what should be used to measure the whole project, what about the short term metrics, and what for the long-term goal. LOC is definitely not a good one, but what about others? World changes rapidly, are other metrics always good ones? Probably not, and those are all things that we need to explore.
References
[1] Clapp, J. (1993). Getting started on software metrics. Software, IEEE, 10(1), 108-109.
[2] Sudhakar, P. G., Farooq, A., & Patnaik, S. (2012). Measuring productivity of software development teams. Serbian Journal of Management, 7(1), 65-75.
[3] Boegh, J., Depanfilis, S., Kitchenham, B., & Pasquini, A. (1999). A method for software quality planning, control, and evaluation. Software, IEEE, 16(2), 69-77.
[4] Jeffery, R., Curtis, B., & Metrics, T. (1997). Status report on software measurement.