Not so simple code.

We want our code to all be simple, but sometimes it’s not that easy.

We had three examples of complicated code and they all had different levels of crazy.

In this particular example there was a host of pain that stopped the code being simple. There was the obvious (== vs === or ‘this’) problems that are associated with legacy JavaScript and a few other typical code smells (big methods, lots of local variable capture, inconsistent naming).

The more interesting stuff to me was what made it difficult to change.

In this example, the code was so bad that it was tackled in the thermonuclear way. Deleted and replaced with a cleaner implementation with new features.

Our next example was a test that asserted you added new PowerShell cmdlets in a manner consistent with the existing. The goal is laudable — we want consistency! The way in which this was achieved didn’t help achieve that goal.

A lack of documentation meant that test failures didn’t tell you the why. Why is “Should have been of type X” important?

The result was jumping through hoops and editing the code until the test passes without really understanding the why.

Our final example was a monster. The code was so big that the print out made an audible thud.

The code had a seemingly simple reason for existing. Given a data structure, generate a SQL statement. This should be ideal for writing a unit test for, right?

Well, not so fast.

The end result was that instead of writing a “proper” test, the new functionality was added and unit-tested in isolation. This is great, but the bigger beast still remains.

OK, so we now we’ve got complicated code. What are we going to do about it?

There’s a motivation theme that prevents us doing stuff sometimes.

At Redgate, we’re not typically hugely deadline driven. It’s really unlikely you’re going to have to make that compromise between speed / quality. We want to do things right. However, maybe we’re not creating the conditions to encourage that. We ask how long till X? Maybe that creates the perception that all we care about is performance?

We also realized that there’s a grab bag of tips and tricks for dealing with legacy code. Just in a simple read through of the code we found we shared loads of techniques.

We’re going to try and extend this by introducing a Code Clinic. If you’re staring at some Not-So-Simple code and want the benefit of a fresh pair of eyes, post a message on our Slack channel and a willing participant will pair until we’ve beaten it to simplicity.

I’ll leave you with a quote from Julia about legacy code.

Related posts:

Tired of men talking over you? Does it happen in meetings, the classroom, or even with your friends? Does this plight of internalized patriarchy follow you everywhere you go? Have no fear, these…