Out of this I’ve gained the impression that TDD is a technique intended to favor a particular style of coding. In the past I’ve heard TDD promoted as a technique that makes it easier to write “better” code, but without containing claims as to what counts as “better.” Now I’m thinking TDD (as we know it) is being advocated by people who have particular preferences, and that what TDD helps most is implementing according to these preferences.

If this is so, what does it imply for languages that don’t fit the preferred style? If this is not the case, how would we criticize this notion to identify the error?

private static int[] setWeights = new int[] { 0, 1000, 200, 300, 400, 500, 600 };
private static int[] diceWeights = new int[] { 0, 100, 0, 0, 0, 50, 0 };

Member: Score(int[]) : int
Maintainability Index: 63
Cyclomatic Complexity: 9
Class Coupling: 3
Lines of Code: 6

The written requirements mentioned “sets of three X dice faces…” not “occurrences of X dice face”. Based on that I supposed items should be contiguous to be counted as a set. If I had supposed they didn’t need to be contiguous I’d have devised the following implementation instead:

private static int[] setWeights = new int[] { 0, 1000, 200, 300, 400, 500, 600, 700, 800, 900 };
private static int[] diceWeights = new int[] { 0, 100, 0, 0, 0, 50, 0, 0, 0, 0 };

static int Score(int[] diceValues)
{
return (
(
from item in diceValues
group item by item into dice
orderby dice.Key
select new
{
Dice = dice.Key,
Score = (dice.Count() / 3 * setWeights[dice.Key]) +
(dice.Count() % 3 * diceWeights[dice.Key])
}
).Sum(item => item.Score)
);
}

I think readability and maintainability are very important, and they aren’t necessarily measured by metrics. If by adding some extra if statements and methods I can make my code easier to read, then I think that’s a good thing. Let’s say that we added more rules to the Greed game, and someone other than you and I had to modify the code we had written (this happens all the time in real life). How hard would it be for that person to get the job done?

Like you said, your code probably is faster, but in this case, performance wasn’t really a consideration. Certainly if it were an issue, I might have to refactor something. But I’m guessing that the difference in performance is negligible anyway.

Again, the goal of the TDD session was not to see how fast we could solve the problem. We could’ve gone faster if we weren’t trying to demonstrate how to do TDD (which was the main goal of the whole thing).

The point in this workshop was not speed of implementation or (premature) optimization of the code. It was a learning excercise. You are kidding yourself if you think the people running this workshop couldn’t have knocked out that Greed engine in no time with a full suite of unit tests in full TDD fashion. The idea was to take the time to focus on how it is done for the people who don’t yet understand how to do TDD on a non-trivial task front-to-back.

But the most important metric is correctness of implementation. The whole thing is bunk when you come down to the fact that your code isn’t correct. By ignoring the testing and just slinging code, you left it open for bugs. What if you send yours {1,5,1,5,1}? You return 400. The correct response is 1100. It’s because you assume the sets of 3 are in runs, when they can be separated.

Don’t take it personally. Egoless programming is even more important than TDD. You are not defined by your code.

@Jon
Can’t wait for the recording. I hope to spread it around the office. Finally getting some buy-in on TDD around here, but I think it’s at the “but it will be too hard” phase for some.

Please take a look at the following code metrics (static analysis) produced by Visual Studio Team System 2008 Development Edition and compare:

Type: GreedScorer
Maintainability Index: 66
Cyclomatic Complexity: 48
Depth of Inheritance: 1
Class Coupling: 3
Lines of Code: 62

Member: Score(int[]) : int
Maintainability Index: 50
Cyclomatic Complexity: 16
Class Coupling: 0
Lines of Code: 21

Although, your implementation has a maintainability index a bit higher than mine (16 points up), your implementation has a cyclomatic complexity 3x higher than mine (why complain about my fors, switches and ifs, as some of your blog followers did in the comments, when my implementation has a much much lower cyclomatic complexity), your implementation has Depth of Inheritance and Class Coupling, whereas mine does not have. Moreover, you implementation has 3x the lines of code mine has.

I haven’t run a dynamic code analysis (profiling/instrumentation) to compare implementations, but just reviewing your code it becomes clear it has performance implications. It iterates through same array so many times, whereas mine iterates through the array items just once.

If I had commented my code, maybe it would be friendlier to some, but come on people, I implemented it in less than 5 minutes. How long did it take you to implement yours? As far as I remember, a whole afternoon. Don’t be so rude on me, please.

Your presentation about TDD was great, when looking at the WHAT perspective (how to create the tests, what tests to undergo, etc., etc.), but when it came to the HOW part, it seems you, people, got lost and implemented something not that simple, just to satisfy the requirements your tests carried on. While the #swe101 was live (underway), I asked you, people, to use and adapt my implementation (the HOW perspective), so that to avoid wasting so much time on it and to check my implementation (the HOW part) was conformant to the tests you created (the WHAT perspective), but no one took it into account.

If TDD was to sacrifice performance, increase complexity, depth, coupling and lines of code to write, I wouldn’t jump in for sure. Fortunately, it is not, as far as I am concerned about. Just an advice, pay much much more attention to the “WHAT perspective” next time and make things as simple as possible. I may not know much about the WHAT, but I know a lot of the HOW, since I review, refactor, fine tune and try the simplest wherever possible.

I don’t want start a war here (we have a lot out there already) and I won’t go any further on this. Just needed to come up and defend my code. That’s what I do for living for long.

Thanks and regards,

Luciano Evaristo Guerche (Gorše)
Taboão da Serra, SP, Brazil

We did record it. Hopefully it worked. :) I’ll blog about it if it gets posted somewhere.

Jon