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.
14 Responses to “The Blame Game: How Necessary Is Traceability?”
You forgot one important benefit that comes with traceability: knowing who to talk to when you’re not sure why a piece of code was written the way it was.
I don’t know what you guys are putting in the water up there but you make too much sense sometimes.
While on the surface I agree with this idea, some of the logistics it introduces would violate some regulatory rules I’m sure. Of course, those rules were written by the very chickens of which you speak.
I’m going to have to go ahead and disagree with you there. Like Kevin, I’ve found the ability to know who to talk to invaluable. I use the TFS “Annotate” feature regularly when I have to dig into existing code. Rather than spending half an hour tracing through someone’s code manually trying to figure out exactly what it’s doing, it’s been much faster for me to just say “Hey, Bob… what’s this thing doing?”
If I was to run this experiment, no doubt that I would hit some snags – especially on larger teams than I am currently working with.
By no means am I going to argue with your points Kevin and Mel, because they are good points, but let’s just play devil’s advocate for a second…
If your team is needing traceability in order to provide “what’s this thing doing?” visibility – does your team not have code readability problems (otherwise known as Code Solubility)?
Again we could fix this problem in the front-end rather the back-end…just another thought…
[…] The Blame Game: How Necessary Is Traceability? (Max Pool) […]
If you have a team where traceability becomes a blame issue, I think you need to address that problem.
The accountability factor can be critical if there is a breakdown (especially in deployed code) and you need to figure out how it happened and what the lessons and process improvement need to be.
If you don’t want to trace to the developer, you need to trace to those actions that were used to affirm that the code was all right and maybe what the approval process was.
If we are egoless, doesn’t that mean everyone owns the code as if it is theirs, and they own the defects the same way? The traceability is because you need it, along with that.
@Max Pool
I agree that if your code base is 100% easily grokable and well-commented, then traceability is not very important. So yes, you could say that. But you could also say that if your team needs unit testing then does your team not have code developing problems?
From my experience, there is *always* code in a project that is a bit hairy. Sometimes it’s the developer’s fault (bad code). Sometimes it’s the project’s fault (unrealistic deadlines). Sometimes it’s nobody’s fault (the algorithm is just naturally very difficult to understand without some domain knowledge). Regardless, there will come a time where the ability to trace down the original developer is not only useful, but necessary.
So to counter: if your team is using traceability to play the “blame game”, doesn’t your team have ego issues that need to be looked into first? I would think that solving the behavioral issues would be more effective than removing a tool that has other useful purposes other than facilitating this behavior.
WHOA there, Max. Are you saying that unit testing is only needed for teams with development problems? If your team isn’t unit testing, then your team quite definitely has problems.
Testing isn’t something you do to solve existing problems. Testing is something you do to prevent future problems.
@Kevin and @Mel –
Nope, I fully support unit testing – that’s you putting words in my mouth 😉
…and yes, any team that is playing the “blame game” will (and does) get a stern talking…that type of crap does not fly with me…
The idea of eliminating traceability is only an idea for increasing an egoless and unified development team. Perhaps it is an idealistic extreme that can never work, but it is a thought towards producing ego-free teams that produces highly soluble code.
The traceability is useful for identifying more systematic problems. For example, if in one month you run into 3 resource leak issues, did you have 3 people who each caused one of them, or did you have one developer who caused them all? If it was one person, perhaps pointing them in the direction of some training, or pairing them with a developer who is strong in that area, would resolve the issue.
To channel the 80’s: “Knowing is half the battle!”
[…] Traceability Matters 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 […]
[…] a link to a post I did yesterday on the subject of traceability and metrics. It is in response to Max Pool’s post on CodeSqueeze. Between Max’s post and my post, I think we cover most of the key arguments around […]
Traceability doesn’t make sense until your credit card grows legs and walks away 🙂
Regards,
Slava Imeshev
Solubility schmolubility. I’m looking at some code right now, and I understand exactly what it’s doing from a code perspective. It’s copying a value from a payment definition (template) into an actual instance of a check. I have no trouble understanding the CODE, but I wasn’t in the domain walkthrough with the original developer, so I’m lacking the BUSINESS knowledge that he had. It’s easy to throw out a word like “Solubility” or a phrase like “Self-documenting” and say that all our code should be readable by future developers, but when you’re working on complex business processes, there is a lot of information that you can gain by asking a simple question rather than trying to re-live part of another developer’s life. I can slog my way through all of the original feature documentation and learn it all myself, or I can just say “Hey, Dave, why are we copying the gross amount to the check instead of the net?”