In Part 1 of this three-part series, I examine what can and can't be reliably learned from a simple heuristic measure, lines of code. In Part 2, I will illustrate how you can employ VS.NET IDE macros to obtain lines-of-code measurements and how you can use macros in general as a productivity tool. In Part 3, I will demonstrate a pattern that can discernibly improve a software development team. All of these elements work in concert, as I will show. Each article is useful alone, but together they will provide you with invaluable tools and skills.
Progressing as a programmer or programming team requires improving upon what has been done in the past until some optimal level of skill is attained. But, how can any programmer or team improve without measuring the current level of proficiency? Knowing for sure whether improvement is occurring may be difficult, if not impossible.
One heuristic measurement that is easy to obtain is lines of code. Lines of code is a weak heuristic (I will tell you why in a minute), but it is an easy place to start and it does have some value.
Good Heuristics and Bad
On a day-to-day basis, you can measure how many lines of code you and your team are producing. However, lines-of-code counts in and of themselves will not tell you anything about the quality of the code produced, whether the code solves the right problem, or whether the team is improving. As such, lines of code can be either a good heuristic or a bad one, depending on whether or not it's used properly. For example, zero lines of code may mean that your people are stuck, spending too much time in meetings, or just goofing off.
Consider this scenario: Yesterday my team of five produced 1,000 lines of code but today produced only 125. Is this meaningful? Maybe or maybe not. To be sure, I know that the team produced 75 percent fewer lines of code. They could have spent time doing other things. Perhaps today's problem was substantially more difficult than yesterday's. Or it could mean something else entirely. Who knows for sure? What the measurement does indicate is that you have a heuristic that, if included with other heuristics, is a starting point for measuring progress.
The lines-of-code measurement is a stick in the sand that, when considered with other factors, is a starting point. It marks the beginning of your productivity tracking. If you use lines of code as the only determinant for whether to reward or punish your programmers, then you are using them incorrectly. However, if you use them as a starting point and evaluate how new lines relate to your schedule (I prefer daily and weekly milestones), they can be useful.
Look at your schedule. What meaningful work was due during a given interval? If the lines of code represent a completed problem for a given interval, the measurement is more meaningful. If the lines of code do not reflect a solution specifically designed to solve part of the overall problem, more investigation is needed. For example, if the lines represent a utility that really enhances productivity, you need to evaluate them in terms of how much of a productivity improvement the utility provides.
The next thing you need to know is whether the new code is refactored and whether it employs known design patterns. Consider the alternate scenario: Yesterday we did 125 lines and today we did 1,000 lines. If the lines of code are not refactored, but instead represent repetitive, copied-and-pasted code, we have no real improvement at all. Lines of code are the gateway to knowing all of these things, but they tell us nothing by themselves.