What it takes for TDD to make Clean Code That Works?

"Great books begin with great openings. 'Test-Driven Development' by Kent Beck (2003) begins with this sentence: Clean code that works, in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development (TDD)." (Quoted from talks by Takuto Wada (和田卓人), or t_wada, the TDD evangelist actively working in Japan.)

When I teach about TDD, I always try to stress that TDD is just a skill and that's Clean Code That Works you really want. To supplement this idea, I came up with an diagram.

It was interesting to find out that the 'Works' part can be split into two: It works as intended (Verification) and also it works to fulfill expectations (Validation). In other words, code is not broken (Verified) and valuable (Validated). So, it must be validated, verified, and clean to be called as clean code that works.

TDD is chiefly an activity for developers or programmers. But other people also see values in Clean Code That Works. Clients would receive no value if a part of code does not work. Testers will be relieved if code is already confirmed to work. Programmers who need to read and modify someone else's code will feel safer if the code is clean.

In the Red-Green-Refactoring cycle, programmers make sure the code is clean and verified (Green and Refactored.) Sometimes they also know how to validate, i.e. make sure it's valuable to anyone who receive the software. But sometimes other people are required for validation. So, along with Programmer, I add two kinds of people to the diagram: QA (tester) and Client.

This version of diagram gives us some ideas of who values what: Programmer want the code verified and clean. QA (tester) make the code validated and verified. Client likes validated and clean code. Maybe clients doesn't care (or doesn't know) about clean code, but they sure value ease of change. Safety and easiness in modification is a great virtue of clean code.

Lower half is usually where programmers put focus with TDD cycle. The diagram will help remembering that validation is also crucial to make sure the code really works. And help from other kind of people is essential to validate programmers' work. Everyone helps each other ― everyone works for each other, outside of TDD cycles. Or, perhaps, everyone participates in TDD cycle as a mob!

It may be a good idea to use the diagram in workshops to gather activities to create Clean Code That Works. Draw three big circles, label them Validate / Verify / Clean. Write down ideas, processes, activities or tasks on sticky notes and then put them into appropriate areas. Find out lacking activities, discuss about collaborative overlaps, define your Clean Code That Works, look for ideas for improvements, or do anything you like to do together.

Now I have a worry that the diagram might send a wrong message. It is meant to all three - Validated / Verified / Clean - are important, but someone might read like "I'm a programmer, so validation is none of my business." To mitigate my fear, I made another version of the diagram with two dotted arrows.

I'm not really sure what the arrows mean. Maybe I can say like "Programmers are not only responsible for Verification and Clean but also for Validation. To do that, programmers need to collaborate with clients to understand and share client's vision." I'd like to hear what do you think of the arrows, or rather, any versions of the diagram.