Don’t repeat yourself. It is a great advice for writing code. However, it isn’t the only place it is applicable.

Let’s look at a super simple description of software development roles and their artifacts:

Customer: requirements, acceptance tests
Developer: code, unit tests, module tests, acceptance tests
Tester: module tests, acceptance tests

See the overlap? If customers, developers, and testers aren’t working together, we are creating waste through duplication. Even if we are working together, we can do better.

What if worked in such a way that the customer requirements can be run as the acceptance tests and acceptance tests can be viewed as customer requirements? What if architectural requirements can be run as unit tests or module tests? Or, vice-versa?

You can see where I am going with this. We are still creating a lot of waste because of duplication. If we can work within some framework (that doesn’t necessarily mean a tool) that seamlessly allows us to have requirements as tests and the other way around, and reuse tests between customers, testers, and developers, we can make some real gains in efficiency.

Furthermore, working in this manner reduces duplication in communication. Everybody is working with the same “stuff”. This “stuff” serves as documentation as to the expected behavior and real behavior of the system. There should be less time spent talking about the same thing amongst the various roles.

We are all essentially working on the same “stuff”. So, why not act like it and identify areas of duplication and reuse?