Putting aside the issue of developer availability, why does it seem so hard to find competent developers willing to work with legacy systems?

What is a legacy system?

Legacy systems/codebases/databases are everywhere. “Legacy” just means it already exists and, from the developers’ perspective, the system has been inherited from other developers, meaning the developers who produced the system are no longer around ¹.

^{1. Sometimes we imagine them laughing at us from hell.}

A case study

Allow me to recount my experience with probably the worst legacy codebase I’ve had the displeasure to encounter. Here is how the first conversation with the client went.

So you have a close relationship with another development agency, but you don’t want them to work on this particular system? Tell me more about that.

…They quoted you 6 months for the work, but you need the features in 6 weeks.

…They are the third agency to work on the codebase, and the previous agencies weren’t very good.

So the current version of Ruby is 2.x. What version of Ruby are you using in this system?

…1.8?

Ah I see you’re using MongoDB.

Oh Rails 2.3. The latest version of Rails is 4.x. We should upgrade to the latest version if possible.

…Oh you didn’t upgrade because several of the ruby gems have not been updated and don’t work with the latest version of rails.

The codebase has tests, right?

…More than 10,000 automated tests. That sounds… comprehensive.

…Different developers liked different testing platforms, so some wrote tests in minitest, some wrote tests in capybara, some wrote cukes and some decided to rewrite tests in rspec without deleting the minitest versions… Hmm, so some duplication in the tests is to be expected. Well I guess we’ll certainly know about it if we break anything.

…Oh wait the test suite doesn’t run.

[some time later]

Hmmm. There are over 2000 failing tests. Is this code in production?

…It is?

…To save time and money the last group of developers didn’t bother fixing any tests they broke. Riiiiiight.

There are a lot of developer comments in the code.

…Wow. There’s a lot of swearwords in these developer comments.

There’s over 400 TODO task comments. Looks like theres a lot of technical debt.

…Your developers didn’t use an issue tracking system, and instead managed technical issues in inline code comments. I see.

So you’ve said your other development agency will handle deployment of the code, so how do you want this to work? Github pull requests?

…Your other development team still use Subversion?

And this is the systen your business relies on for most of its revenue?

If you’re a developer you will probably be hearing the alarm bells, a claxon, and maybe even a foghorn too. This was undeniably a terrible codebase we were being asked to work on.

Terrible legacy systems are not a deal breaker for developers

The perception that it is hard to get good developers to work on legacy codebases is wrong (or, at least, doesn’t apply to us). Although it’s no secret that developers don’t enjoy working with legacy systems, good developers thrive on bringing order from chaos, even if the actual process is not easy.

So why does it seem difficult to find developers to work on legacy codebases.

Maybe it’s…

There are many reasons a developer or agency will decline a project, but, while there is a correlation between horrible legacy systems and horrible projects, the legacy system is not the cause of projects going bad. Instead bad systems are often associated with bad clients, because bad clients make bad decisions that cause systems to go bad. Bad clients are also, not surprisingly, not good to work with. It is the clients themselves that are often both the cause of bad systems and failed projects.

So, if you find that developers don’t want to work on your legacy system, then maybe, just maybe, the problem isn’t your system: maybe it’s you.

But there is hope: bad systems don’t necessarily mean bad clients

At this point you might be surprised to know that we accepted that unpleasant sounding legacy system job described earlier in this post.

Certainly the success of a project depends a lot on the client, and whether the client will be good to work for is our number one consideration when deciding whether to take on a project. However, when we are presented with a terrible codebase we don’t just assume the client is going to be terrible to work with.

In the case outlined above, the poor quality of the codebase, was not reflective of the client.

The client listened to us. They took on board what we were saying. They were pleasant people. Their expectations were not unrealistic and their requests not unreasonable. Many of the obviously bad decisions made in the past were either due to the client receiving bad advice, or were poor decisions made by the previous developers (not the client).

So if you have a legacy codebase that is getting a little dog-eared and needs some loving care and attention, you can do something about it, and wanting to do something about it is the first step towards being a great client (so get in touch now).