Two things brought me to write this post. The first one is the reading of a series of articles about immutability by Eric Lippert. In particular, Eric Lippert presents a clever implementation of an immutable binary tree.
This immutable binary tree has a powerful property: it does not allow creating cycles. You can’t make of an element a child of one of its descendants. It is an “emerging” structural property of the data structure. And I insist it is a simple, straightforward code. Let’s say it: Eric Lippert Kept It Simple and Smart.
Here is the second thing: last week, I attended a Coding Dojo organized by Valtech. The principle of the Coding Dojo is simple: we choose a problem on which we practice Test Driven Development and pair programming for example. The aim is to experiment, to learn and to share observations on development practices (more than to solve the problem). The pair [developer/reviewer] works in a time-boxed round under the eyes of an observer and then, alternatively, the roles are switched.
While the problem was exposed to the group, I quickly had a big picture on my head, identifying the main modules and responsibilities. (The chronometer started) I began to expose my first impressions to the team, “Perhaps we could start with..” Halt! Apparently I had gone too far. My team-mates preferred to cling to an important principle of TDD, “do the simplest thing possible that works” and do it right now. One pulled me back, stick my head towards our IDE and quite quickly, all together, we produced a piece of code. A piece of code that do.. something.., rather primitive but, well, it was there.
A concession, a compromise, a least, we had our first lines of code. Ok, a good point for TDD.
Thus, here is which my observation was: it is more difficult to make accept a vision than to do the simplest thing possible! :-)
Actually, I cannot do without a continuous test-first approach. I practice in a TDD-like manner, more strictly at the beginning of the implementation. But for me, the moments of reflection at the beginning are essential. And it takes always the time that it takes.
Then, this is the point. Let’s imagine this situation: how any TDD mates can approach the following problem: “Design a binary tree that does not allow creating cycles”
One can refactor and refactor (and refactor again), I bet tests will never drive us to an implementation such as Eric Lippert’s one. Instead, we will have a “binary tree that does not allow creating cycles” made of intricate tests, cycle detectors managed with run-time exceptions.
After all, what could justify such a specific data structure? Perhaps we ain’t gonna need it! And anyhow, is this “emerging structural property” really testable?
Sadek and I thought of this image to describe the architecture that can be produced by a TDD approach to resolve certain problems: “a building made of disparate, ill-assorted blocks which would be functional but of a completely indistinct aspect”.
