Saturday, July 14, 2012

Real-word TDD

At the recent Entwicklertag conference in Karlsruhe, three colleagues and I gave a tutorial on 'TDD in the real world'. The basic idea behind the approach was that to establish TDD as a programming practice (in actual development projects), you need more than just to understand the TDD cycle and practice it on a few sandbox examples. You also have to make it into a habit, and you have to develop a skill. The exercises at the tutorial were designed to help participants make a start in this direction.

We have now made the materials from this tutorial available online; along with them, I have written a series of articles on the thinking behind our approach. You can find both the materials and the articles at

Have fun!

Saturday, May 12, 2012

Who gets the time — man, or machine?

I just stumbled over an interesting observation from an old time (about an even older era):
Mathematicians were so conscious of efficiency considerations that they could not imagine wasting any extra computer time for something a programmer could do by himself.[1]

Today, it's the other way round. The situation has changed, and so have the instincts of programmers. The primary task today (in mainstream programming) is to transform a domain requirement into a system's behavior, and that requires thinking on a higher level than algorithms and computations. Those things are assumed to be implemented already (both correctly and efficiently) in compilers and standard libraries. Smallish details of the code are taken over by tools: syntactic correctness is checked by compilers, type checks are done either statically or at runtime by compilers or runtime environments, semantic properties of code passages are verified by unit tests and code contracts.

What all these have in common is that they can be executed in milliseconds by a stupid machine. It's not necessary for the programmer to keep details about the execution flow, data vectors and so on in mind all the time, verifying them every so often silently in the head or empirically in the debugger. This is a waste of time, energy, and attention. Such details are specified and encoded once and then verified periodically in an automated manner. So the motto for programmers today is the exact converse of what Knuth and Trabb Pardo observed about the past: programmers nowadays are becoming once again conscious of efficiency considerations, and thus more hesitant to waste any brainpower for something a computer can do by itself.

If you think about it, that is how it should be. What Knuth describes is an anomaly, a unusual phenomenon. Historically, whenever people started to use some kind of technology, be it the wheel or the steam engine, the goal was to get rid of tasks and chores, not to take them on. Machines are tools, not gods. They shouldn't get the best of your time and abilities, but they're precisely there to take over everything else so that the higher powers of mind are freed from stupid, repetitive work and can be dedicated to pursuing higher-level goals — of which no machine has any understanding (at least, so far).

[1] From Donald E. Knuth and Luis Trabb Pardo, "The Early Development of Programming Languages", in: A History of Computing in the Twentieth Century. Ed. by J. Howlett, N. Metropolis, and Gian-Carlo Rota, New York: Academic Press 1980, 197–274. Didn't look it up myself, quoted from another article.

Wednesday, April 11, 2012

The olfactory quality of our language

Our language influences what we think, and our thoughts (or attitudes) sometimes guide our choice of words. And as with many things in life, some choices may look good in the beginning, even gain widespread application, but then become questionable on reflection.

One such choice is the term code smell, which typically refers to a code passage that cries out to be refactored, 'cleaned up'.

It's a very cleverly coined term. It associates certain patterns of bad coding (bad, because they make code less clear or more difficult to maintain, extend, or change) with a nasty experience that we all know. The analogy goes even deeper: bad smells in real life, once you have noticed them, are hard to ignore, and usually we have some impulse to do something about them, to eliminate the source of the stink. Likewise a 'code smell' is supposed to trigger action: reworking the code, cleaning up. Nowadays, every programmer knows what a code smell is; that is, everyone understands the notion, even if not necessarily everyone at all times recognizes typical smells when they encounter them — or at any rate, not necessarily all smells are in fact cleaned up. (At least that's what I often see in practice.) But everyone at least understands the idea of what a code smell is.

Cool, so what's the catch?

In a paper a few years ago, Kent Beck has written about "the engineer’s approach to change: find a problem, solve it"[1]. This way of going through the world and looking at things, however, "is biased negatively and it ignores whatever is going well". As Kent writes, this negativity will drain your emotional energy, if you make it into a general approach to thinking about what to do next. In effect, it will make it harder to achieve change. "Change is not aided by the dominant engineering problem/solution metaphor, where the world is seen in terms of problems to be solved."

Now, these insightful words were written about change, that is, about modifying the way we work, for instance when we start adopting the XP practices. What I want to suggest is that they equally apply to 'normal working mode'. When we are in the middle of everyday coding, we're also in danger of getting into a problem-response mode of acting. And when we're using words like 'smells' to describe to ourselves what we are doing, we cement this way of looking at things. (The effect is compounded when we use it in conversation, face-to-face or digitally, with other developers.)

When you are coding, what habitual attitude do you have towards the code base on which you are working? Do you think of it in terms of 'problems' (to be solved), or in a more strongly, colorful language, in terms of 'smells' (to be cleaned up)? Observe yourself during an average day of coding; make a list on a sheet of paper: how often do you change production code, and what exactly is it about that code which triggers action? How do you think and feel about it? The difference here may be subtle, but compare "Hey, these two passage look as if we can generalize and have a single, elegant query object!" with "Damn, there's this stinking code duplication again, I have to eliminate this!" It doesn't just feel bad when you recognize the pattern (in this case, a code duplication) in the code and instinctively classify it as 'smell'. There's also not much satisfaction to be gained after you have acted and changed the code. You've just changed a 'bad thing' to an 'ok thing'. Moreover, this kind of situation is likely to happen repeatedly, all over the day. Thus we establish for ourselves a feedback loop very effective in creating a general mood of frustration day after day.

So, we might have second thoughts about an outlook, sedimented in terminology, that encourages us to reduce stimulus-response patterns to problem-response patterns. (To be sure, even looking at things in terms of stimulus-response is a narrow mindset. But we're making it even more narrow by favoring a notion of triggers to action that is negative.) Such an outlook is very much suggested by speaking of 'smells'.

To widen our perspective: the notion of a 'code smell' is not the only notion that works this way (though it's probably one of the most ingrained). Generally, becoming more aware of the language we use when we think about what we do in our daily work pays off — even if it's just a small step that brings some fresh air and lets us look at a code base without a continuously crooked nose.