Prime Programming Proficiency, Part 1: Lines-of-Code Heuristics
Use What You Have Learned to Improve
Given the present scenario, you know your team has a certain number of lines of new code. The questions you need to answer are:
- Were more lines, fewer lines, or the same number of lines produced as the prior equivalent period?
- Do the lines of code solve a problem that is part of the scheduled solution? If not, why not?
- Is the change in productivity proportionately relative to the schedule? That is, if more meetings were scheduled or people were in training, is the difference relative to the amount of time spent not programming?
- Was the complexity of work greater or less than the previous period's complexity? New problems take longer than common problems.
- Is the quality of code better than the previous period's quality? Is the team using refactoring more consistently? Are known design patterns employed? Are known anti-patterns avoided? What is the change in code quality?
- Are programmers repeatedly handling a problem that a pattern, component, or code generator could reliably solve much more quickly?
If you are measuring and examining lines of code, you should be able to discern whether the code is good, refactored code, or buggy, messy code.
Lines of code do not answer any of these questions. They simply provide a starting point for isolating and then evaluating newly produced code. It is the answers to the questions above that will indicate where your team needs improvement.
In Part 2 of this series, I will demonstrate how to use VS.NET macros to measure the lines of code in a solution. You can use other tools, such as Visual SourceSafe (source control) to isolate new lines—and all of this is much easier to do with a project plan and a schedule.
Take the First Step
Lines of code are a heuristic that is akin to drawing a line in the sand. Unfortunately, lines of code are the first step in a journey of a thousand miles. One must isolate newly produced code and evaluate it relative to the schedule, the complexity of the problem, and the qualitative aspects of the code. Not doing so is working in ignorance of measurable productivity and quality.
Paul Kimmel is the VB Today columnist, has written several books on .NET programming, and is a software architect. You may contact him at firstname.lastname@example.org if you need assistance or are interested in joining the Lansing Area .NET Users Group (glugnet.org).
Page 2 of 2