Oh my God, what have I done?

As I write this, I’m sitting in the hotel apartment in Italy. I’ve left my wife & 16 week old son in the UK while I spend two weeks working for a new company in Italy. In January, all three of us move out here for at least the next three years.

Oh. My. God. What the fuck have I done?!

The Bad

Day two was pretty bad. The full enormity of it all suddenly hit home. I can’t make myself understood – I need others to do everything for me. I can imagine how my son must feel – no way of communicating and totally reliant on others. To be honest, it’s a wonder I didn’t start screaming at the top of my lungs and shit my pants.

After work I had to navigate, in the fog and dark, a route I’d never driven before – to find my way home. But before I could kick back and relax with a nice glass of wine, I first had to do battle with the supermarket and buy the wine. As well as food for the evening. Plus also pans to cook the food in. And knives to prepare it with. And… and… and… Clearly people staying in this apartment don’t cook. I mean, to call it under-stocked is to do a dis-service to apartments without kitchens. Totally fucking useless. Anyway. Easily solved. Just more money down the pan.

Then when I got home, the useless toilet paper carrier bags snap and the shopping crashes to the floor. Everything survives. Oh, except the wine. God-fucking-damnit I needed that.

After a day of hearing how critical it will be to live in the right area; and for my wife not to be bored out of her mind by moving here – I find out that the tantalizing prospect of my wife being able to continue working for the same company but from Italy, had been snatched away from us. This means my wife will be unemployed. In a country she doesn’t speak the language. With an economy going down the toilet. We expected this. But it’s still annoying.

I mostly spend the evening worrying what on earth I’m doing out here. How are we going to survive? Life in the UK with a 3 month old baby has been hard. How will we cope in a country we don’t know our way around, where we can’t speak the language? What the fuck will we do?

The good

Day three on the other hand, has been much better. After a day feeling useful at work – I mooch home, stop via the supermarket and buy yet more things I’d forgotten / couldn’t find the day before. So today I get home and can actually cook a meal (a bolognese, how appropriate). I even get a glass of wine. Or three. And suddenly today feels like a much better day!

But why? I’m starting to get to know a few of the ex-pats. Starting to get an idea of where we ought to live. Starting to feel that my wife might not be completely isolated. It sounds like there really is the community out here I’d heard about / hoped for. Ok, Sam still needs to get involved and settle in – but at least today I think it’s possible.

And at work the team – to my great relief – actually seem pretty fucking awesome. Sure, there are challenges. Sure, there are some issues. But they seem to basically want to do the job right. They seem to basically understand what it takes. I’m not sure why that hasn’t always happened, maybe they think they don’t have permission? But perhaps that’s where I come in. After all, if Software Craftsmanship is about anything – it’s about raising the bar, it’s about encouraging other developers to do the right thing, it’s about giving them permission to do it right. So here’s hoping this is a great opportunity to help a team excel, to do the job I believe in and have an influence in an industry I’ve loved for years.

All-in-all – I’m hoping I’ve made an awesome, massive, life-changing decision that will be full of win for all three of us. Of course, having lunch with and meeting people you know off the telly puts the squee level into fucking over-drive. Oh. My. Fucking. God. I really am working here.

Tomorrow will now be an utter piece of shit disaster making me wish I was back in Blighty. Hey ho. Gotta love the roller coaster of life.

Apologies to people expecting this to be a blog about technology. Normal techie-ranty-goodness will resume shortly. Life-with-a-capital-L just slightly more on my mind at the minute.

Update: further posts on this topic will be at my new blog, specific to our move to Italy: English South Of Milan.

Dealing with technical debt

We’re drowning in technical debt. We have a mountain to climb and don’t really know where to start. Sound familiar? For many of us working on legacy code bases this is the day-to-day reality. But what to do about it?

How did we get here?

Technical debt is always the fault of those “other guys”. Those idiot developers that were here a few years ago. Morons. Obviously couldn’t code their way out of a game of life if their on-going existence depended on it.

I hate to tell you but: we are those other guys. The decisions we make today will look foolish tomorrow. We’ll have more information then, a different perspective; we’ll know how the product and technology were going to evolve. We can’t know that today, so many of our decisions will turn out to be wrong.

Where to start

Classes are like best-selling novels – some are spectacularly more popular / more debt-laden than others. One class, one package, one module – will be much worse than the others. There’ll be a handful of classes, packages etc… that are much worse than all the rest.

How does this happen? Well, one class ends up with a bit of technical debt. Next time I come to change that class, I’m too lazy to fix the debt, so I just hack something together to get the new feature done. Then next time round, there’s a pile of debt – only that guy’s too busy to fix it so he adds in a couple of kludges and leaves it. Before you know it, this one class has become a ten thousand line monster that’s pure technical debt.

It’s like the broken-windows theory – if code is already crappy, its much easier to just make it a little more crappy. If the code’s clean, it’s a big step to add in a hack. So little by little, technical debt accumulates in areas that were already full of debt. I suspect technical debt in code follows a power law – most classes have a little bit of debt, but a few are really shitty, with one diabolical class in particular:

technical debt graph

Where to start? Resist the temptation to make easy changes to relatively clean classes – start with the worst offender. It will be the hardest to fix, it might take a long time – but you’ll get the best bang-for-buck by fixing the most debt-heavy piece of crap code. If you can fix the worst offender, your debt will have to find somewhere else to hide.

The 80/20 rule

There’s a cliché that 80% of the cost of software is maintenance, only 20% is the initial build.

Let’s imagine a team that has 1200 hours a month to spend on useful work. For that 1200 hours of useful work, we’ll spend four times that much over the lifetime of the software maintaining it – from the 80/20 rule. Although we completed 1200 hours of feature work this month, we committed ourselves to 4800 hours of maintenance over the lifetime of the code.

That means next month, we have to spend a little of the 4800 hours of maintenance, with the rest of the time spent on useful, feature-adding work. However, adding new features commits us to even more maintenance work. The following month, we’ve got nearly twice the code to maintain so spend nearly twice the amount of time maintaining it and even less time producing value-adding features. Month-by-month we spend more and more time dealing with the crap that was there before and less and less time adding new features.

productivity graph

Does this sound familiar? This is what technical debt feels like. After a couple of years the pace has dropped; you’re spending half your time refactoring and fixing the junk that was there before. “If only we could get rid of this technical debt”, you cry.

What is technical debt?

We can all point to examples of crappy, debt-laden code we’ve seen. But what’s the impact of technical debt? Technical debt is simply an inability to quickly make changes to an existing system. This is the cost to the business of technical debt – what should be quick changes take an unpredictably long time.

What do we do when we remove technical debt? We generalise and find more abstract solutions. We clarify and simplify. We remove duplication and unnecessary complexity.

The net effect of reducing technical debt, is to reduce inventory.

Perhaps the amount of code – our inventory – is a good approximation for the amount of technical debt in a system. If I’m confronted with a million lines of code and need to make a change, it will probably take a while. However, if I’m only confronted by 1000 lines of code the change will be much quicker. But, if I’m confronted by zero lines of code, then there’s zero cost – I can do whatever I like. The cost of making a change to a system is roughly proportional to the size of the system. Large, complex systems take longer to make changes to than small, self-contained ones.

All code is a liability – the more code you have, the bigger the debt. When we’re paying back technical debt – are we really just reducing inventory? Is what feels like technical debt actually interest payments on all the inventory we hold?

What are the options?

Big bang

One option is to down-tools and fix the debt. Not necessarily throw everything out and rewrite, but spend some time cleaning up the mess. The big bang approach to dealing with technical debt. It’s pretty unusual for the business to agree to a plan like this – no new features for a year? Really? With no new features for a year what would all those product managers do all day?

From the 80/20 rule, the lifetime cost for any piece of code is four times what it cost to create. If it took three months to make, it will take a year to pay back. So wait, we’re gonna down tools for a year and only pay back three months of technical debt? Seriously? We’ll be marginally better off – but we’ll still be in a debt-laden-hell-hole and we’ll have lost a year’s worth of features. No way!

Dedicated Team

Even if you try to do big bang, it ends up becoming the dedicated team approach. As a compromise, you get a specific team together to fix the debt, meanwhile everyone else carries on churning out new features. One team are removing debt; while another team are re-adding it. What are the chances that debt is being removed faster than it’s being added? Exactly. Nil.

It makes sense – you need a team removing debt four times bigger than the team adding new features just to stay still.

Boy Scout

You could adopt a policy of trying to remove technical debt little and often – the boy scout approach. On every single development task try and remove debt near where you’re working. If there are no tests, add some. If the tests are poor, improve them. If the code’s badly factored, refactor it. The boy scout rule – leave the camp cleaner than you found it.

This is generally much easier to sell, there’s only minimal impact on productivity: it’s much cheaper to make changes to a part of the system you understand and are already working in than to open up whole new ones. But over time you can massively slow down the rate at which debt grows. Inevitably the system will still grow, inevitably the amount of debt will increase. But if you can minimise the maintenance cost you’ll keep the code small and nimble for as long as possible.


If we can lessen the maintenance cost of code even just a little we can save ourselves a fortune over the life of the code. If we can reduce the multiple to just three times the initial cost, so our 1200 hours work only costs 3600 hours in maintenance, we’ve saved enough development capacity to build another feature of the same size! For free! Hey, product manager, if we do our job better it’ll take no longer and you’ll get free features. Who doesn’t want free features?

If we can create well-crafted, DRY, SOLID code with good test coverage we have a good chance of minimising the lifetime maintenance cost. This is the best way we can keep our productivity up, to try and avoid getting mired in technical debt and keep the code base responsive to changing requirements. It’s the only way we can remain productive and agile.

Frankly, anything else is just unprofessional. If you’re deliberately committing your company to spend excessive amounts maintaining your shitty code – what the fuck, exactly, are they paying you for?