In a recent blog post on CodeSqueeze (http://www.codesqueeze.com/the-blame-game-how-necessary-is-traceability/) the subject of traceability and its utility in software project management was discussed. This post is a response to the author’s points on traceability. While I agree with the author on some points (especially that traceability can be used proactively), I believe that traceability has much greater utility in the development process and in the management of software projects.

Traceability, both at the code and issue levels, provides you with fundamental process metrics. By removing these metrics, you lose objective insight into the state of the project. Using such metrics for a blame game may indeed be a sign of poor project management, but not having the metrics at your disposal is a sign that you are not controlling the process, and that puts your project at risk. I can’t imagine other engineering disciplines such as chemical engineering even having this conversation – you measure (almost) everything that can be measured, and then determine which metrics are most useful in improving the process. The best engineers on your team will welcome objective measurements into their code – like having the fastest time at the racetrack, doing well by a set a metrics that are not easily manipulated is something to be proud of, and something for more junior engineers to aspire to.

As for feature traceability, some of the comments on the blog point in the right direction - for example, that in regulated industries, such traceability is a requirement. ‘We all trust each other’ doesn’t fly well with the FDA or DOD. But even beyond the regulated industries, traceability and related metrics answer questions that are too basic to leave unanswered:

- what requirement did this code satisfy?

- what ancillary issues (bugs, related requirements) is this code associated with?

- how long did it take compared to the initial estimate?

- how often since the fix was marked as ‘complete’ did the code change?

I could (and just might) write another blog post on why these metrics are interesting and essential to software process management, but for now I leave it to commenters to elaborate.

To the specific points that the author makes, lets look at them in turn. The author’s orginal points and counterpoints are in italics.

• Provides visibility of per person velocity – Visibility can occur during daily stand ups and weekly powerdowns.Sure it can, but that implies among other things that you are doing such standups. What if you are using an alternate process to coordinate the efforts of large, widely distributed teams? At some level, independent of your specific process, you need to be able to look into your SCM system and answer questions of who is doing what and why. Also, (and this touches on the second issue of accountability) not all developers communicate in the same way, so even if you are doing standups, as a manager you need objective facts to correlate with the verbal and written communications of your team.

• Creates a sense of accountability – Why the hell do you have people on your team that you don’t trust?  Trust doesn’t happen all at once. The basic principle of managing people, whether they are shipping clerks or software engineers is ‘trust but verify’. Once a person has established a track record of reliable communications that are consistent with the objective (and hopefully, automated) metrics, you might reduce the frequency of how often you check them against the metrics. But periodic checking is essential – if a previously reliable engineer has for some reason fallen off the tracks, they may be reluctant to admit it, or they may not even be aware of it. A properly constructed metric that is trending in the wrong direction will give you clue that there is an issue to be addressed with this engineer.

• Allows for possible learning opportunities – Either the bug is a bug (and no real lesson is to be learned), or senior developers did not properly guide less experienced devs through a design problem. All bugs teach you something. The latter case that the author mentions is certainly one lesson, but it implies that senior developers don’t write buggy code or are somehow immune to design problems (or design-to-implementation translation problems) of their own. This seems unlikely. Most of the best engineers that I’ve worked with will admit to some whopper bugs – many written well after they had earned the title of ‘senior engineer’ or ‘chief cook and bottlewasher’, or whatever. What a bug tells you is that you have code that needs attention, independent of whether it dropped out of a build process or was discovered by the janitor. The overhead for recording a bug, commenting on it and connecting it to the source code change that resolves it is minimal in a well-designed and well-tooled development process, so for a small amount of effort you get the benefit of a window into your code, its failings, and your process. Seems like a low price to pay for such potentially valuable information.

I’ll admit that traceability and metrics are on my mind often (see for example, my prior post on the AccuRev-Rally integration and how it assists in agile requirements traceability). Maybe it’s because my favorite toys as a kid were ruler, compass and slide rule and I just like measuring things for the heck of it. Or maybe it’s because I’ve seen too many engineering projects fail – projects that if the manager (myself included) had a bit less hubris and a few more objective facts at their disposal, could have been squarely in the success column.