About the code. The problem with small-scale “code katas” (or even worse, small-scale code katas within the context of a specific language), is that we easily slip into the mindset of solving the problem through clever usage of language features, like map-reduce. In this sense, I’m relatively skeptical about their contribution when your goal is to explore the design space.

Still, you probably remember that I solved a similar problem (yahtzee, http://www.carlopescio.com/2011/06/cut-red-wire.html), explaining my reasoning while writing code. I would probably point people in that direction (including the “limits and confessions” at the end).
But again, design is way more than that. It’s about understanding forces, materials, choices, consequences, recognizing familiar structures, exploring different venues for the fun of it, etc etc. Constraining all that within a few principles is terribly sad :-)).

Curiously enough, though we tend to disagree on many things here and there, your final suggestion (“Make your code look like a model of the problem!”) is very much aligned with the DSL approach I took for yahtzee. Again, I see this agreement/disagreement mostly as the inability of contemporary design narrative to faithfully represent our (largely shared) sensibility for “good design”.

http://groups.google.com/group/software_craftsmanship/msg/84106f8a09a9486c

#1 can be trivially satisfied by writing few or no tests :-)

These 4 elements are meant as a compass for people doing Extreme Programming. In this context you don’t even have to mention “no tests”. In general, the real meaning of this first rule is that “working code is worth more than non-working code, no matter how beautifully designed.” Working code driven by test is base one. Almost everyone learning XP is able to get to this stage. The difficul bit lies in satisfying the later rules :-)

#2 is not a measure of simplicity, per se. We usually remove duplication by abstraction. Some people find abstract code harder to read (I normally don’t, but I’ve met many).

I disagree. Simple is not easy. Finding the right way to remove duplication is not always easy, and it’s not easy because there might be more than one way, and some ways are worse than others. It may happen that you in removing duplication we add complexity; this usually means that we have not found the right abstractions, or that we have not finished removing duplication.

#3 is too fluffy, which is unfortunate (see below).

#4 is stacking the cards against structural complexity (while still ignoring coupling altogether) but says nothing against procedural complexity. So, a single long method with no duplication and a huge switch/case inside would score as “simpler” than a number of small classes with short methods.

To be fair, the compensating force for #4 is #3, as “expressing ideas” should push you to introduce concepts, through classes and methods. Unfortunately, #4 is easy to grasp and calculate, #3 is ambiguous and fluffy, so they don’t really balance out.

It is true that #3 cannot be measured as easily as the other rules. So be it. Nobody promised that we could find the best design by a mechanical search in the space of possible solutions. We have to think; we have to decide what ideas we want to express. This is why it is not true that a single, monolithig procedure would score “simpler”. Rule #4 is a warning against letting our ego run free with unnecessary abstraction or generality.

That’s particularly bad for people in early stages of skill acquisition, who lack the maturity to understand nuanced concepts.

True. I’m beginning think that the unspoken assumptions behind XP was that everyone had the design and coding skills of Ward Cunningham. Kent Beck wrote plenty about how to code effectively in SmallTalk, but wrote very little (in comparison) on how to code effectively in XP.

I find that reasoning about and practicing the consequences of these 4 rules is an essential step towards becoming proficient at TDD.

But Carlo, since you say that design is way more than these four rules, what would *you* say about the solutions such as the one above, and the many other that can be found on Stackoverflow? What would you say to these students from the perspective of your knowledge of design?

Simplicity is one of the many informal-yet-useful properties of a good design. It’s just not enough to declare a design “good”.

Honestly, even as far as simplicity is concerned, I find the 4 principles lacking.

#1 can be trivially satisfied by writing few or no tests :-)

#2 is not a measure of simplicity, per se. We usually remove duplication by abstraction. Some people find abstract code harder to read (I normally don’t, but I’ve met many).

#3 is too fluffy, which is unfortunate (see below)

#4 is stacking the cards against structural complexity (while still ignoring coupling altogether) but says nothing against procedural complexity. So, a single long method with no duplication and a huge switch/case inside would score as “simpler” than a number of small classes with short methods.

To be fair, the compensating force for #4 is #3, as “expressing ideas” should push you to introduce concepts, through classes and methods. Unfortunately, #4 is easy to grasp and calculate, #3 is ambiguous and fluffy, so they don’t really balance out. That’s particularly bad for people in early stages of skill acquisition, who lack the maturity to understand nuanced concepts.

Overall, the entire set of principles is heavily biased toward design-as-code, henceforth preventing any useful design conversation at larger scale. This is something I discussed in an older post (http://www.carlopescio.com/2011/02/is-software-design-literature-dead.html)

Useful compass? Perhaps. Still, design is way more than that :-)