Short: An example of learning as the result of rotating; using techniques learnt from working with testability in new (TDD/BDD) development.

On the microlevel, we learn from inspecting the code we are creating. On the macro- or project level, we learn skills in one type of project that we can use in a project of another type. Essentially, the difference between legacy and greenfield. Working with many legacy projects, we can see the results of our mistakes, and we can see how we can work around them.

This turbocharges our learning, since the issues are magnified.

I've experienced a useful example are TDD/BDD techniques. BDD gives us insight into our software designs, it illuminates values of our designs that are very hard to find otherwise.

I think it was Pete McBreen (or maybe Alistair Cockburn) that drew the parallell to how many martial arts methods are taught, usually in several levels - the masters have apprentices that teach the novices. The novices magnify the mistakes of the apprentices. The mistakes become easy to see, the feedback is clear.

 We get this magnification when we look at code a little further on the timeline, when it has been in production for a while. The problems caused by any design decisions we made when developing make it easier to see how design affects maintainability.

For most of 2006 I have been working with projects where the challenge was in making the code testable and then adding tests. I have discovered that when I return to new development projects, many of the techniques I learned while working with existing code have helped my understanding of the BDD issues.

So for this example, if you haven't done any "refactoring old code" project, and haven't read the WELC book - I recommend doing it. There are many things you will learn from it, testability techniques not the least.

Rotation is good, both in the small and in the large.