#08-TDD Captures Institutional Knowledge Permanently

How can we keep track of the behavior of systems as they change over time?  We must do this, or critical enterprise knowledge can be lost, at potentially great cost going forward.  This episode is about how TDD solves this problem.

Transcript

TDD Captures Institutional Knowledge Permanently

Many organizations have large, mission-critical legacy systems that must be updated and maintained over time, but that no one currently in the organization understands very well.  The people who designed and built these systems have been promoted, moved on to other jobs, retired, or even passed away.  The knowledge that was in their heads went with them.

This can cause massive problems. Lost knowledge is waste, of course, but it also impedes the ability for the organization in question to capitalize on opportunities, maintain market share in the light of unpredictable competition, and to innovate.  These legacy systems are hard to maintain because of this lost knowledge, and so changing them requires excessive time and effort.

The solution would seem to be to adopt the policy that all systems must be thoroughly documented in the form of some kind of functional specification or other document set.  The theory is that these documents will preserve the knowledge of those who write them.

Unfortunately, this does not really work reliably.  As these documents age it becomes increasing difficult to ensure that they remain up to date.  Often people will make changes to a system and fail to update the specifying documents, either because of time pressure, or simply because they don't realize these documents exist.  The real problem, of course, is that there is no way to determine if they are, in fact, still accurate.

In TDD we create the test suite to drive the development forward.  Because the tests come first they specify the behavior we create.  But they do so in a way that can be verified at any point, even years in the future, by simply executing them either through automation or as part of a manual testing process.  If they still pass, then you can be sure the behavior of the system is what they say it is.  The knowledge is not lost, ever. We know of no other reliable way to accomplish this.

Of course this assumes that the tests were written properly: in a way that fully captures the nature of the requirements they represent, and also in a way that will be readable later to someone trying to regain the knowledge that existed when they were created.  This is a matter of training and is a big part of how we teach TDD here at PMI.  See the transcript for a URL to a useful resource.

See this page for details on PMI's training solutions:
https://www.pmi.org/business-solutions/agile-training/technical-solutions