Cory stops his analysis when he has the following model:

|Cell| <------- |Status|
           |Alive|    |Dead|

At this point Cory says

“Certainly if we implemented a Cell with a Status object with an AliveStatus class and a DeadStatus class someone, somewhere, should slap us upside the head.”

However, I’d like to carry on from that point just a little further…

I like to teach the use of CRC for exploring design, and so I naturally looked at Cory’s objects from the point of view of their behaviours and responsibilities. Thus it struck me that if we don’t make the split suggested by Cory, we’d have a Cell that knows about its position/neighbours and knows what change to make when the clock ticks. That would violate the Single Responsibility Principle. So the above split into Cell and Status makes sense from the point of view of responsibilities, if we give the Status object the job of deciding how the Cell should change.

With those responsibilities in mind, a little mental CRC session suggests that, when the clock ticks, the Cell would tell its Status object how many neighbours it had, and ask for a new Status object in return.

class Cell
  def change
    @status = @status.update_based_on(@number_of_neighbours)
  end
end

The Status objects become Strategy/Policy objects, and thus don’t seem to need any instance state. All of which means that the Status objects could be Flyweights, with only one extant instance of each type, referenced by every Cell that happens to be in the corresponding state.

I think this approach could well be worth a punt during the upcoming Global Day of Coderetreats…

When I see a duplicated algorithm, it seems that my natural tendency is to push up the skeleton into a superclass. This creates an inheritance relationship within the algorithm, which in turn makes it harder to change. Later, when I do need to change the algorithm, I have to change the superclass and all of the subclasses at the same time. For example, one particular superclass in reek contained three or four template methods, which made the subclasses look quite odd; and each little complex of template-plus-overrides significantly hampered design change in each of the others.

Looking back over my programming career I see that I’ve always had this tendency — I can see it in my old C++, Java and Ruby code. I wonder why? Is it the cost of extra classes, or my mathematical background, or coding habits ingrained before the rise of object-oriented languages? Who knows (and who cares).

So, note to self: Break out State/Strategy objects (and in Ruby this includes Procs) instead of always relying on TemplateMethod.

I’m not a huge fan of Rails, and I’ll post more of an answer here later, when I have a little time. In the meantime, what do you think? Can Rails teach everyone to be better?

I’ve always (ie. at least for the last twenty-five years) kept a to-do list during each programming episode. The list begins with one entry, describing the goal I’m working towards. And as I read and write code, new entries are added to make sure I go back and fix or refactor everything I see along the way. Until recently, those additional entries tended to describe an outcome – “split class Foo to create Bar and Xyzzy”, or “wrap x and y into a Mouse class”, for example. But recently I’ve noticed myself tending to write entries that describe the problem – “class Foo too large”, “x,y travel around together”.

I have no idea how, why or when this change happened, but I’m pleased it did. Between the time I write a particular to-do item and the time I finally get around to executing it, I may significantly change the code in that area. Or I may learn something about the code and where it wants to go next. Or the problem may disappear, as a side-effect of some other change. Either way, the solution I might have on my to-do list has a chance of being inappropriate now that the code and I have moved on. So by listing the problem as I originally saw it, I’m giving myself a much better chance of creating the right solution for it – because I’m deciding on that solution in the presence of the full facts.

I’ve recently been re-doing a few kata that I first tried a couple of years ago. I’ve noticed that my results are dramatically better now, mostly I think due to delaying the moment at which I decide how to solve each micro-problem. This effect is an example of Mary Poppendieck’s “decide as late as possible” maxim. There are clear benefits in terms of the quality of my designs; and there are psychological benefits too, because I don’t have to spend time trying to remember why I wanted to do each item on the list. Everyone wins.

The article also provides a brief overview of rSpec, a new framework for BDD in Ruby. Great package, shame about the name (say it aloud)…

Once of my current bug-bears is the lack of design done by agile teams. I know we all chant “design is good, so we design all the time”, but in reality it just doesn’t happen. Switching from legacy habits into test-first thinking and good object design is a really hard jump. The programmers’ habits have to be turned inside out, and the focus on tests seems to me to have a negative effect. I hope the emergence of BDD frameworks like rSpec and jBehave will help to make it easier for programmers to make that transition.

Update, later the same day
Elizabeth Keogh posted a nice description on the extremeprogramming Yahoo group, showing that switching to BDD is not just about replacing “test” by “should”.

• check-in working, tested code at least every ten minutes;
• when pairing, switch driver after at most ten minutes;
• if a design session lasts more than 10 minutes, it must be attempting to solve a problem that’s too big to be a single chunk.

Because to make these work effectively, a number of other things have to be in place. Such as a fast build and “vertical slice” thinking.

I’ve heard these misconceptions many times before – that UML is either a design tool or (worse) a design process. It isn’t. It’s a notation, based on an underlying set of concepts. Knowing UML does not make one capable of design, any more than one can become a chef simply by recognising food types and kitchen utensils.

UML has become an industry in itself. I can understand the commercial forces that caused it to happen, but I can’t help feeling that the resulting situation contains more negatives than positives. Sure, vendors can ply standards-conformant consultancy, CASE tools and training courses, but far too many people think that UML brings an essentially creative and intellectual skill (by which I mean software design) into the broader world. “Knowing” UML does not de-skill analysis or design. Knowing the UML notation does not make one a designer. But not knowing that does make one dangerous.

So I stepped back from TDD and tried to get the team to only produce well-factored code from now on. Another failure, and this time the legacy code was only partly to blame. It turned out that only two of the fifteen people on the team really understood what well-designed object-oriented code looks like. The rest wrote working algorithmic code, and were completely blind to the duplications and strong couplings they had created. For lots of reasons, including timezone differences in some cases, it was impractical to pair with everyone to help them towards an understanding of ‘simple’ code. So I did a few public worked examples via NetMeeting, and still had almost no impact on the code being produced. I guess that refactoring is a design skill, and that it has to be taught, because most programmers don’t learn to appreciate ‘good’ code in university.

Anyhow, pressed for time and somewhat frustrated, I tried another tack. I wrote up a series of simple metrics that all new code must pass. And again I publicly refactored a piece of legacy code to remove all duplication, showing at the end that the resulting code did indeed now pass the metrics. The metrics themselves are purely a response to that particular situation, but may nevertheless prove interesting (they applied to Java code):

1. every JUnit test must run in under 1 second
2. maximum of 1 if statement per class
3. 0-2 fields per class
4. 0-1 arguments per method
5. 1-3 statements per method
6. fewer than 6 imported classes per class

Of course ‘bad’ code can still pass these tests. But I was trying to get across an understanding that each method and class should do only one thing. So I made it very difficult to find enough space to do two things!

Did they encourage the team to write better code? I’ll never know, because the project was soon cancelled…