Do you ever have the situation where someone on your team says,
“I’m not the best person to investigate that bug, Alice knows that part of the system better”?
“I’m blocked until Bob is available to take a look at this, as he was the original author”
“Trevor wrote that part, and since he’s left, we don’t have a good understanding of what it does, so fixing it will be hard.”
If you were to dig deeper, what would you think the problem was?
a) The entire team is not trained up on the whole code base
b) there is lots of silo’d work, causing gaps in knowledge
c) There are human egos at play, not wanting to step on each other’s feet (or on their code)
d) There isn’t good enough documentation to help developers learn the code base
So, which one is it?
It could be all of them.
How do you fix it?
You could require pairing on work; that would be a slow investment, with a long term payoff (but typically worth it, no matter what)
You could have lunch and learns about parts of the code base; though this sounds only slightly more enticing than watching paint dry.
You could “require” code reviews by two or more random people; and assign metrics to how successful those were; though that would have its own problems (I don’t recommend this, but I’ve seen it happen).
You could require Developers write documentation, or hire a BA or technical writer and require they write the documentation. This is only slightly more successful than pushing a string, and about as useful to developers in learning the system.
Or, you could do something else entirely. Something enticing to developers, useful to everyone in de-silo’ing knowledge, and something that shuts down the “only Trevor understands that part well enough”. It could provide a usable level of developer domain documentation.
The problems you hear from your people are symptoms: Your system isn’t built to be shared. It isn’t built to be accessible. It isn’t built for to be resilient against turnover.
One of the many benefits of adopting Test Driven Development is that you’re adopting change that helps your organization become resilient to turnover, resilient to bottlenecks in knowledge transfer; and allows developers across your team to understand parts of the system they have no knowledge with.
Such a change doesn’t happen overnight. It takes work and practice, and it’s as much a cultural change in how your team approaches solving a problem as it is a technical strategy.
But the real question is: Can you afford the cost of turnover, the cost of knowledge silos, and the cost of showstopper bugs at the last minute before delivery? The real alternative to Test Driven Development is to do nothing, and you already know that cost. You’ve experienced it.
To help teams achieve their full potential and to lower the cost of change while increasing team happiness and productivity, I now offer TDD immersion training and mentoring for .NET Teams.