The Blame Game: How Necessary Is Traceability?Filed Under Human Factors, Software Process
As we know, egoless development environments are necessary for a productive learning environment for our teams; however, I have been knocking around the idea of conducting an experiment and completely eliminating any traceability within the software process.
Here is my thought: with the exception of “fail fast” pieces of the software process (such as the build server), why is it necessary to know exactly the when and who someone created a feature or a bug?
Knowing this information does not eliminate nor lessen the burden of correcting the problem – the only thing it promotes is negative finger pointing.
The most logical arguments for granular code/feature traceability would be:
- Provides visibility of per person velocity
- Creates a sense of accountability
- Allows for possible learning opportunities
I can not argue that these are good points, and that I myself use traceability to my advantage when keeping a team on track. However, I will argue that all of these points are covered if you have hired the correct people and run them in an efficient manner. For example:
- Personal Velocity – Visibility can occur during daily stand ups and weekly powerdowns
- Accountability – Why the hell do you have people on your team that you don’t trust?
- Learning – 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
My point is that the problems that traceability solves, do have equivalent solutions that occur at a much more proactive level.
The majority of times, the people requesting this level of traceability end up being people that have very little participation in the project (Scrum chickens). Guess what they use it for…a quick gauge for “the blame game”! I have never seen this information used for the benefit points listed above at the managerial level. At this level of traceability analysis it is all about who fucked up (which must be the logical reason why the project is doomed).
Use traceability to your advantage so you can better react to the “now” and forget using traceability for what has happened – no reason to go on a witch hunt…you have bugs to fix.