Refactoring is much easier...

Refactoring is much easier when you have clearly expressed intent.

This came up a few days ago when I was talking with Steve and Nat.

We were holding a lunchtime retrospective about the latest delivery of our TDD course.

We talked about what had worked well, what we could do differently, and how we could customise the course for audiences with differing requirements.

Nat and Steve were keen to develop an exercise that would focus on refactoring. I liked the idea but I also wanted to keep an existing exercise which brings to life the value of intentional programming.

I felt that the ability to express intent was even more fundamental than the skill of refactoring.

It's risky to refactor unless you can check whether the code still does what is wanted. I don't think you can do that easily unless the tests and code express intention.

Nat reminded me that what you express, and how you express it, is different in code and tests. Good tests remind you of intent when they fail. This makes it easier to diagnose the cause of failure.

Refactoring is easiest with clean code, and clean code expresses clear intent. (Of course, as Steve pointed out, everything is easier if you have clean code).

You might refactor because the intent is not clear, but there are other reasons to do so. For example, you might refactor in order to make the code easier to change.

"The ability to pay back debt...depends on you writing code that is clean enough to be able to refactor as you come to understand your problem"

Ward Cunningham - Debt

Conclusion: we will develop a module on refactoring, but we'll keep our emphasis on writing clean code and tests that clearly express intent.

GetInLine version 2

I'm currently working on GetInLine 2 - a complete rewrite of GetInLine, a record-processing DSL I wrote a couple of years ago.

The DSL is not yet as fluent as I would like, but I'm much happier with the underlying design. I'll also be switching to an Apache license; James Strachan encouraged me to do this for version 1, but I never got round to it.

I'm following the development approach that Steve Freeman and Nat Pryce advocate in their book (and which the three of us expound in our TDD course).

I started with a failing end-to-end test. Then I used mocks and unit tests to help me to pull the required interfaces into existence, filling out the application until the first end-to-end test passed.

The resulting code is much simpler to test and write than v1 was, and I've ended up with a highly pluggable set of components.

I'll post a URL as soon as GIL2 is ready for beta testing; if anyone wants to tale a look before then, let me know.

Opportunism knocks

I've just angrily binned an invitation from the Professional Conractors' Guild.

I'm a PCG member, and I've been very happy with them. If you, like me, work as an IT contractor in the UK you'll find they offer an excellent and valuable range of services. I routinely recommend them to colleagues. So -what did they do to annoy me?

They invited me to their tenth birthday celebration.

For which I would have had to don a DJ and pay them £60.

Why on earth would they think I'd want to do that?

I'm glad they have been going for a while, but not glad enough to fork out £60. Even worse, I'd have to spend the evening talking to other IT contractors - and we'd all be wearing dinner jackets.

If the economy had been booming I'd just have tossed the invitation in the bin, but with things as they are the invitation was about as welcome as an invitation to play a round of golf with Fred the Shred. (I assume he plays golf, on the grounds that he must be good at something.)

So, PCG: I won't be joining in your narcissistic celebration, and please don't waste my membership fees on promoting events like this in future.

Read "Rocks into Gold" and spread the word!

I've just read Clarke Ching's Rock's into Gold on SlideShare. It's a delightful short story which explains how incremental delivery can improve cash flow, saving jobs in the process.

I first met Clarke at XP Day a couple of years ago. Several friends told me how much they liked his Introduction to Agile Development, so I went along. I'm glad I did.

Clarke's presentation was excellent - clear, simple, business focussed, and very compelling. So's Rocks Into Gold. I've started to use it as a resource for prospective agile adopters; I may even save a few jobs!

Read it and spread the word.