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”.
[...] http://juliendelhomme.com/?p=53 del.icio.us, digg+ [...]
Pingback by Sadek Drobi’s Blog » REFX :: You are not gonna need it: isn’t that, the simplest thing that work? — January 17, 2008 @ 10:56 pm
Hi, Julien.
I’m reading Domain Driven Design (Eric Evans) recommanded by Sadek. I found there a lot that I have seen… somewhere ;o) Good book, interesting, I enjoy it during my “holidays”. BTW, good code I have seen with you there, thanks again !
Could you add to your article somme links to read about immutability ? It is a concpet I barely understand… I know *what* it is, but not *how* it works, and *how* to use it intelligently. I didn’t understood why it is interesting to use in concurrent programming. Anyway, I’ll try the other articles by Lippert.
Tks. Say hello to your teammates for me.
J.
Comment by TheGuyWhoLeftInDecember — January 18, 2008 @ 11:47 am
Hello Mr J.
The series of Eric Lippert is a nice introduction to the implementation of immutable data structures.
You should have fun with Lucas Bolognese and Wes Dyer, too.
Lucas Bolognese - Creating An Immutable Value Object in C#
Wes Dyer - Immutability Purity and Referential Transparency
You will find applicability of the concept of immutability in the field of functional programming.
Purely functional programs have no side effects. Consider this paradigm when you have to deal with concurrency, or state-oriented computations for example.
And to finish, it is a good thing that you talk about Eric Evans’s Domain Driven Design since immutable entities and Value Objects (datatypes as immutable classes) play a very big role in DDD. You will find in the book how these concepts are used in a DDD approach.
Comment by Julien — January 18, 2008 @ 3:42 pm
Good post Julien. I definitely agree.
However, I am embarrassed with comparing my every day coding with the exercise of writing a perfect “binary tree that does not allow creating cycles”.
What I code every day is a lot simpler and for specific algorithm, I like to reused well known solutions.
And I would add that what is true to me as a single coder is even more true when talking of a team (most of the time composed of programmer of different level and experience).
But then, I agree. TDD can /still/ drive you to “a building made of disparate, ill-assorted blocks which would be functional but of a completely indistinct aspect”. I add “still” because, I feel that classical separation of a program by domain of responsibility (as opposed to a collective code ownership) is to me the main cause.
Then to conclude, yes, good design skills is still essential to good programming. ;-)
YAGNI and simple design are two practices mandatory to guaranty a good test coverage. YAGNI at the level of functional tests, simple design at unit level. That’s almost it. If you do yagni or complex design, you will have to pay the coverage debt later if you ever manage to. To me design emergence is more the result of successive iterations of good design practices. It emerge in the sens that it is not decided six months in advance and that it is surprisingly different of what you could have imagine.
My two sens…
Etienne
Comment by Etienne Charignon — January 25, 2008 @ 10:22 pm