
How do you get to Kernighan (and Richie) Hall?

Random Thoughts: Measuring Technical Debt

The Blindfolded Ninja Model of Software Development
Scaling: Local vs Full Vertical scaling

The three failures of Continuous Delivery

Top Gear: A New Refactoring Kata

Don’t Refactor. Rebuild. Kinda.
I recently had the chance to speak at the wonderful Lean Agile Scotland conference. The conference had a very wide range of subjects being discussed on an amazingly high level: complexity theory, lean thinking, agile methods, and even technical practices!
I followed a great presentation by Steve Smith on how the popularity of feature branching strategies make Continuous Integration difficult to impossible. I couldn’t have asked for a better lead in for my own talk.
Which is about giving up and starting over. Kinda.
Learning environments
Why? Because, when you really get down to it, refactoring an old piece of junk, sorry, legacy code, is bloody difficult!
Sure, if you give me a few experienced XP guys, or ‘software craftsmen’, and let us at it, we’ll get it done. But I don’t usually have that luxury. And most organisations don’t.
When you have a team that is new to the agile development practices, like TDD, refactoring, clean code, etc. then learning that stuff in the context of a big ball of mud is really hard.
You see, when people start to learn about something like TDD, they do some exercises, read a book, maybe even get a training. They’ll see this kind of code:
Example code from Kent Beck’s book: “Test Drive Development: By Example”;
Then they get back to work, and are on their own again, and they’re confronted with something like this:
Code Sample from my post “Code Cleaning: A refactoring example in 50 easy steps”;
And then, when they say that TDD doesn’t work, or that agile won’t work in their ‘real world’ situation we say they didn’t try hard enough. In these circumstances it is very hard to succeed.
So how can we deal with situations like this? As I mentioned above, an influx of experienced developers that know how to get a legacy system under control is wonderful, but not very likely. Developers that haven’t done that sort of thing before really will need time to gain the necessary skills, and that needs to be done in a more controlled, or controllable, environment. Like a new codebase, started from scratch.
Easy now, I understand your reluctance! Throwing away everything you’ve built and starting over is pretty much the reverse of the advice we normally give.
Let me explain using an example.

Extending the Goal in Scrum

Agile 2015 Talk: Don’t Refactor. Rebuild. Kinda.

From Here to Continuous Delivery

XP2015 Workshop: Continuous Delivery using Docker and Jenkins Job Builder
Introduction
On 25 May, I had the opportunity to give a workshop at the XP 2015 conference in Helsinki on using Jenkins Job Builder to set-up a delivery pipeline to build and deploy Docker images. The full source for the workshop can be found on my github account: https://github.com/wouterla/. This post takes you through the full workshop.
The workshop slides can be found on slideshare: