Our Solution

We arrived at a test-driven solution for Soundex. Our solution is by no means the only one or even the best. But we have high confidence that we could ship it (barring the outstanding items discussed in ​What Tests Are We Missing?​), and that’s what’s most important.

I’ve test-driven Soundex a handful of times, each time deriving a different solution. Most solutions differed only in a few small ways, but one was dramatically different (and poorly performing) when I actively sought to solve the problem in an extremely declarative manner. Each pass through the process of test-driving Soundex taught me a bit more about the algorithm, but I also learned more about what works well from a test-driving stance.

You might find similar value in test-driving the Soundex algorithm a few times. The notion of repeatedly practicing TDD against the same example is known as a kata. See ​Katas and Dojos​ for further information on katas.

There is no one right way to code any solution. There are important solution characteristics.

• It implements what the customer asked for. If not, it’s a bad solution, no matter what. The tests you build using TDD can help you understand whether your solution is in line with what the customer requested. Sufficient performance is one of those things your customer likely wants. Part of your job is to ensure you understand their specific performance needs, not introduce the costs of optimization when it’s not needed.

• It works. If a solution exhibits significant defects, it’s bad, no matter how elegant. TDD helps ensure that the software we deliver behaves the way we expect. TDD is not a silver bullet. You’ll still ship defects, and you still need many other forms of testing. However, TDD gives you opportunities to ship code with considerably fewer defects.

• It’s readily understood. Everyone wastes excessive time trying to understand poorly written code. Following TDD will provide you with safe opportunities to rename and restructure your code for better understanding.

• It’s easily changed. Usually, ease of change aligns with design quality. TDD allows you to make the continual tweaks necessary to keep design quality high.

Our solution isn’t very procedural. The complete algorithm isn’t in one function that you can read from top to bottom. Instead, we implemented it in the form of numerous small member functions, most one or two lines long. Each of these functions contains code at a single level of abstraction. Initial encounters with code like this can cause fits of apoplexy: “Dagnabbit, where’s all the work happening?” To learn more about why we code this way, refer to ​Benefits of Small Methods​.