MagRails - Manchester's first Agile & Ruby on Rails Conference

I was at a team retrospective yesterday and we were grappling with some really difficult issues around a lack of tests on a ruck of badly-designed legacy code.

The first point I feel I need to make is that the individuals who wrote this code didn’t fail, it was the system that commissioned the work and oversaw its construction that did. In our Western, individualistic, culture critical comments get taken personally and they shouldn’t be. For me, one of the most powerful things that came out of Magrails was Bob Marshal’s quote from Deming that 95% of an individual’s performance is down to the system they are forced to work with, and only 5% down to the the person themselves. So, if you aren’t in a high-performing team that has goals which should result in well-crafted, considered output, you won’t be able to produce it (in general). And you may not be able to deal with it either, except by going somewhere else. This sucks, but at least you know it’s not your fault and your frustration is justified.

The team want full test coverage and to deal down the non-fatal error count we get from tools like Airbrake so that it’s actually reporting real errors we can do something about, instead of noise about nils that comes from bad design and implementation.

If you talk to a development team, particularly if they inherited the code base, the usual solution to this is to rewrite whatever it is that causes you so much pain. Five years in, with a functioning business who can do that what they need, would be throwing your money away – like that’s going to happen! Instead you need to approach things by following the ideas outlined by Michael Feathers in Working Effectively with Legacy Code spiking new functionality into a new code base and making sure that it’s fully tested, plus refactoring into tests any code you have to touch to add that functionality. Michael’s approach is incremental, and painstaking, but it does give you a solid base over time without a pointless, massive, upfront investment. Read Michael’s book – it’s full of considered detail explaining how to do this. His twitter handle is @mfeathers and blog is here – I met him at Scottish Ruby Con earlier this year and he’s a really nice guy too. Looking forward to his next book, which I believe will be called Brutal Refactoring.

I was thinking about where the development effort is going over the next few months and realised that at least some of the core functionality is being rewritten and repurposed for an internal business function (can’t give details, sorry). The lead developer on this is one of the best devs I’ve ever worked with (you know who you are) and I know that this stand-alone module will be done to the highest standards and have full test coverage. It’s not up for debate, that’s how he rolls.

So, the speculative part of me started thinking instead of trying to polish the current turd, why not build outward from the new shiny? This code is repurposing a lot of customer-facing code – so why not pull that back into the customer facing area and rip out the cruft? It sounds like a good plan, and it is, but also it isn’t.

Where does bad code come from?

I did a talk at Agile North 2011 on YAGNI and there’s a blog post – one of the things that I talk about is how working in silos gives you really maladaptive code. Each silo’s code is probably fine for the silo, but in terms of the whole business it’s rubbish and you have to spend a ton of effort joining the disparate areas together. Not necessarily so bad it kills the business (although I’m sure that this has happened) but in terms of the flow. Using kanban, and reading around the systems thinking ideas (plus John Seddon’s excellent talk ), I’ve come to realise that building outwards from this particular shiny is probably a bad idea.

One of the reasons we’re faced with so much pain is the system was built to run the call centre, and sell our services. Unfortunately, the finance and marketing functions weren’t in the conversation, and there’s a whole heap of nasty compromises and (quite frankly) incoherent crazy stuff, that works, but makes your eyes bleed when you try and change it and has potentially lethal non-local effects. This of course drives the effort to fix or change things up through the roof. But it’s not unusual in a lot of businesses. I have to say I’ve been here before dozens of times.

So, the cost is in the flow. It’s not in the tasks themselves, it’s in handing them off to someone else. For example, Seddon talks about how removing the annoying IVR call centre crap (“press 3 to shoot a pony, press 2 to ride a unicorn, press 0 to speak to someone who is being treated like a robot”) can actually increase capacity by 25% by meeting customer needs straight away and avoiding hand off and customers giving up and calling back etc. He says a lot of capacity is taken up with failure demand. He also says managing by cost makes your costs go up – good eh?

Of course, not managing the team, not doing code reviews, not starting from a place where quality is built in (prevention being far cheaper than cure), is most definitely part of the problem too. But that’s water under the bridge now, and the current team are more than capable of “blowing the bloody doors off”. They also have the full support of the CTO, who is willing to go into battle over the quality issue.

So, ok Francis, what the hell should we do?

This is where I should try and sell you the new book I haven’t written yet, but I’m not going to do that. I’m still thinking about how to do this kind of stuff. My initial thoughts are that the new shiny should incorporate some end-to-end functionality that exposes holes in the existing architecture. Or better yet, starts constructing a new architecture without the existing problems and faults. Then you can build outward from it, by starting with something that crosses all of the functional areas.

I don’t know if this will happen, and I’m moving on to a different job at the end of the week, so I will probably never know. I sincerely hope that it does, because the opportunity to start from a better place is there with a little bit of investment, and the excellent talent doing the work.