24 February 05 - 17:06When to read books

If my behaviour is any guide: don't allow near your source code anyone who's just finished reading Design Patterns. That book was a revelation to me, but for a while after I read it I had an irrational and actively harmful to "do patterns" in everything I was coding.

Over on the French XP Dominic replies to one of our colleagues who's looking for "practical" books on managing a team, suggesting that he should leave off his reading until after he's actually had the experience of managing the team.

I have that pattern. After a particularly rich work experience, or a personal one for that matter, a book or an article which provides relevant explanations or conceptual frameworks can be a fantastic source of insights, and help integrate the knowledge gained from our experiences.

I also have the opposite (but complementary) pattern. I read an interesting book, and three weeks or six months later I find that it has "prepared" me for a situation I'm going through, without my having planned it, without the learning having been a conscious effort. I learn a lot by percolation.

I also remember one occasion where a book, which I'd bought and read for that specific purpose, was hugely useful and contributed to making the gig a success. (That book was Peter Block's Flawless Consulting.) That book has the sort of "how-to" orientation which had proved so dangerous in the case of Design Patterns, but it seems I was mature enough to apply Block's recipes intelligently, this time around; I think I knew already most of them, and what helped most was the step-by-step, "putting it all together" synthesis he presents.

Given all this, my strategy is to read all the time, about every topic that I think I could possibly be interested in - most of my reading eventually turns out to be useful in one way or another. :)

- Private Life Of The Brain - four comments / No trackbacks - § ¶

09 February 05 - 19:28Paying for their profits

On TV yesterday, a piece about how each year, in a 2000-employee business running a factory that cuts up chicken, fifty to a hundred employees develop such bad RSI (repetitive strain injuries) that they need operations, often suffering permanent damage. This to support ever increasing demands of the corporation on their "productivity" (while lines of the unemployed outside grow longer).

The corporation turns a profit of a few fractions of a cent per poultry cut up into pieces, enabling it to outpace the competition, grow bigger, and negotiate with employees from an ever stronger position.

Meanwhile, "unmeasurable" costs to society-at-large accumulate, first in the shoulders, wrists and elbows of those cutting up chicken ever faster. Then in social security costs when these people need their extremely expensive operations, followed by expensive periods of paid- for leave of absense. Then in further social security costs when these people are fired because of disability, drawing a meager pension for the rest of their lives in a lose-lose situation with the rest of society - no longer contributing much, still a drain on everyone else's resources.

Sheesh. Measurement dysfunction at its best.

- The Universe And Everything - two comments / No trackbacks - § ¶

04 February 05 - 09:49Assertions have no behaviour

Are the assertions used in Test-Driven Development the same kind of assertions used in Design by Contract ?

In DbC, two important categories of assertions are preconditions, which express what must be the case before calling a method, and post-conditions, which express what will be the case on returning from a method. Many TDD assertions are also claims about what is the case on returning from a method.

When discussing the two approaches, something I've often heard people ask about, or suggest doing, is writing a test to check that a method will throw an exception if its preconditions are not met. If we don't specify it, and therefore have a test for it, something bad might happen as a result of a failed precondition.

That's the wrong way around ! Rather, a failed precondition is the result of something bad happening. By definition, a failing precondition means that there is a bug in the caller.

Since the bug is in the caller, it is useless to do anything about it in the method that is being called. A method can have any behaviour at all when its preconditions are not met, and that behaviour will be correct by definition.

Using TDD to test for behaviour that cannot be incorrect is a waste of time, and ignores the rules of TDD ("test anything that can possibly break" implies "don't bother testing what cannot break").

I am claiming that wanting to test the behaviour of assertions is a sign of confusion. (I often use the phrase "assertions have no behaviour".) I'm leaving open, of course, the possibility that I'm the one who's confused. But if I'm not, then that confusion about the behaviour of assertions seems somewhat widespread; I encounter it regularly.

I suspect that the problem comes from not drawing a distinction between a program's "accidental" behaviour and its "essential" behaviour. I'm not too happy with the terms, which have a Platonic ring to them, but they're the best I can manage at the moment.

A program's essential behaviours are those that are described transparently by the text of the program. A program's accidental behaviours are those that arise from a particular implementation, or from a particular execution of a particular implementation.

The distinction is important: programmer often introduce defects by relying on accidental properties of their programs. I'll make up an example for illustration. (A "real life" example would be better; I'd be grateful to anyone who sends in suggestions.) Consider a method which takes as input an array and returns the number of unique elements in the array. Suppose that the implementation uses an instance variable to hold a temporary array element, and it so happens that the variable holds the first array element on return from the method.

Counting unique elements is essential behaviour, but providing a way to access the first element is accidental. If we write code that calls the counting method, but then add further code that relies on finding the first element in the variable, chances are that some modification to the implementation, down the road, will remove that property of the counting method.

I haven't answered the question I started with, the following might be a part of the answer: assertions (in both TDD and DbC) document essential behaviour.

- Software Development - seven comments / No trackbacks - § ¶