There has been some discussion of late regarding the use of Test-Driven Development ideas in non-software areas. This is a really good idea and I would like to talk about it here.

Kent Beck introduced “Test-Driven Development” as part of XP. This is a developer-focused design technique whereby developers write  microscopic tests and make them run, in a very short time cycle. The TLA is of course TDD.

XP proponents also introduced the notion of expressing requirements in terms of executable tests that the Customer (PO) understands, used to determine (in part) whether the software does what was requested. These are often called Acceptance Tests or Customer Tests, and facilitate communication of backlog items in concrete terms. By analogy, this technique is called ATDD: Acceptance Test Driven Development.

It’s worth noting that these two approaches, TDD and ATDD, are essentially the same idea: provide a concrete criterion, fulfill that criterion, then repeat. The distinction is of value because the idea is used at two very different levels, a matter of minutes for TDD, and days or longer for ATDD.

Concreteness and clarity are always valuable, even when what is being done is not amenable to executable testing as is software. Can we perhaps extend this test-driven idea to other areas? Certainly we can and probably we should.

Wise product owners will always make their needs as clear as possible. One way of helping teams focus on this is to extend the Customer Testing notion to non-software situations. In these other situations a Product Owner test might be as concrete as a set of measurements that a piece of hardware or furniture must meet, or vague as a set of criteria for hiring a new team member. In all cases, clear communication is enhanced as the criteria are made more clear.

Similarly, we might apply the idea of providing concrete criteria between elements of the dev team, or even for a single dev team member. For example, if a dev team member was building a stairway,  he might find it valuable to build a jig or template to ensure that each step was equally spaced and sized. Carpenters have known this trick for centuries, but we can certainly see that it is an analog of this more modern “test-driven” idea.

Where is the chicken, and where is the egg? We probably don’t care. The basic idea of setting up concrete criteria for the construction of something we want, and checking those criteria as we go, has been around a long time. Two specific instances of this idea have been given the names Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) in the software community, and it’s probably worth reserving those two terms for software, to avoid confusion.

The basic ideas, though, have been around for a long time, and are of value almost everywhere. Let’s use them where they can help us.