So many of us end up in the same place: with an application that we’ve built, as quickly as possible, that has found enough users, and that seems to be getting harder and harder to do any changes to. We describe the state we end up in using terms like legacy system, technical debt, long manual regression cycles, or less polite terms. Working with a variety of companies that have come to be in that position, I’ve found an approach to dealing with these situations.

I recently decided I want to get better at playing the piano. 30+ years ago, I had some lessons playing the electronic organ, but though I’ve played a few things since on a piano I’ve never taken it seriously enough to do some deliberate practice. That means I’ve played a few songs from sheet music, but haltingly and never practiced enough to get the difficult parts right and the whole song memorised.

This is a rambling-about-random-thoughts post. It goes a little out there. Have fun! This post was triggered by the Lean Code talk at #xp2017, by Desmond Rawls (@okokillgo) Using Lean Startup principles to improve code quality. Nick was using the normal code quality metrics for this. That is good, but: not all that actionable, and not showing directly what (I think, and he also seemed to say) the goal is: code that can easily be changed to adapt to business demands.

The ancient and respected team of Science Ninja is amazing. For centuries (or so it seems) they’ve protected the temple of Llabdum. The temple is old, with many places showing signs of previous attacks, or simply crumbling rock and weapons still in the skeletal hands of fallen enemies. Or maybe, you know, just lego bricks left lying about by younger Ninja-to-be. People always marvel at the antics of the Ninja. As they practice moving between different parts of the temple, they put on blindfolds and go from one place on the defences to the other.

It’s funny, isn’t it? Everybody is still talking about ‘scaling agile’. A whole industry has been created on the premise that large companies need process structures to help them manage pushing very large projects through huge sets of development teams. Luckily, the DevOps movement (and the continuous delivery movement, I’m not sure they’re really separate) happened early into that process, so in most of these large scale processes there’s at the very least lip service to the idea that quality needs to be high, and delivery needs to be automated, even if they don’t aim for continuous.

Everyone seems to want to get on the Continuous Delivery train. Rightfully so, I think. For most, though, it’s not an easy ride. From my work with client and conversations with other coaches there’s a few common barriers to adoption. In the end, the goal should be to be able to react faster to the market. And, to be honest, to finally be in actual control. But in business terms, it’s about cycle times.

For the last five or six years, I’ve been using coding exercises during job interviews. After talking a little with a candidate I open my laptop, call up an editor, and we sit together to do some coding. My favourite exercise for this is a refactoring kata that I came up with. I’ve always found it more interesting how people deal with bad code they encounter than any small amount of code that can be written in this kind of short period.

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.

In his post “The Goal in Scrum”, Ron Jeffries makes the case for having a proper, higher-level-than-stories, Sprint Goal. As he says: This is better, because it allows the wisdom and knowledge of the team to be fully exercised, and because it keeps focus on “what” is needed more than on just how it is to be done. The point is well made, and true. Many Scrum teams would be much better off when adopting this practice.

Monday, August 3, I had the opportunity to give a talk at the Agile Alliance’s Agile 2015 conference in Washington, D.C. My first conference in the US, and it was absolutely fantastic to be able to meet so many people I’d only interacted with on mailing lists and twitter. It was also a huge conference, with about 17 concurrent tracks and 2200 participants. I’m sure I’ve missed meeting as many people as I did manage to find in those masses.

Situation Normal There’s a clear pattern for software development. A pattern of lost opportunity. In most, if not all, places where I’m called in the base question deals with the inability to deliver. Management sees that the plans they have are simply not going to be realised. Business opportunities are lost waiting. Waiting for the next available spot in the product roadmap. Waiting for the development team to finish ‘stabilizing’ the system.

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: