6 Tips For Tackling Inherited Code

When this happens it’s easy to slip into a negative mindset. It might be using a structure you are unfamiliar with, seem over-complicated, disorganized, or just different to your regular development approach — it’s rarely plain sailing.

Something built using a slightly different approach can quickly become unmanageable

“It’s not my fault, It’s already a mess” – letting yourself off easy with this type of attitude can create a Frankenstein’s monster of a website if you’re not careful. Something built using a slightly different approach can quickly become unmanageable if every developer who works on the project adds their subjective approach. Whether it be naming conventions, class identifiers or even JavaScript functions.

Below are some tips to help you prepare for and manage inherited websites and see them as something to nurture rather than dread.

1. Ask Nicely for Documentation

Documentation for a site will often exist somewhere in some form. Hopefully! It may be out of date but anything is infinitely better than nothing. When receiving the codebase for a site, always make sure this question is raised early to ensure that any and all documentation is provided during the handover process.

2. Invest the Time Early

Take the time to understand the code you have received. Don’t just glance at it. Invest the time to really look at the file structure, CMS, task runners and whether or not the site is relying on any template engines.

Older sites…can often carry a lot of excess baggage

This would be a good time to start some documentation for the site if it doesn’t already exist, or add your own notes to any existing documentation.

You won’t be able to successfully carry out updates to a site you don’t understand. The result will be obfuscated, bug-ridden code that will only lengthen the time required to carry out even the smallest of tasks.

Make sure you know the site map, how many pages there are, and where the code for those pages is within the structure. This will help you to identify any obsolete or unused code that can be stripped out. Check for unused JavaScript libraries too. Older sites, or sites that have had multiple developers or agencies working on them, can often carry a lot of excess baggage. Anything you can tidy up or clear out will undeniably benefit the site’s longevity.

3. Tackle Unknown Functionality

Don’t wait for it to break! Take a look at any scary functionality on the site and make sure you’re fully aware of any and all complex API integrations. Make sure these are understood and documented clearly.

When working with this functionality, add or update comments in the code to make it clear what functions are doing what and why; saving yourself and others from having to figure it out every time the project is picked up.

4. Keep it Consistent

Learn the system and adjust your code writing habits to fit the current style. Familiarize yourself with reusable classes and functions so you aren’t duplicating any code. This will help reduce overall bloat, increase longevity and improve readability if the site is passed on to another development team.

Adding your own coding methods to an inherited site will make it much harder for other developers to pick up; so although adapting your approach might seem counter-intuitive, a willingness to be flexible is really beneficial here.

5. Spend Some Time in the Analytics

It’s important to familiarize yourself with as much of the site as possible, and digging around in the analytics can give you a lot of useful information. Get to know what devices users are viewing the site on and which browsers require support. Having this knowledge early on means you are prepared when new work comes through and know what fallbacks to put in place and can be prepared for testing.

Always run the site through a site speed test to flag any major performance issues. There may be a few quick wins you can implement to improve the site — such as optimizing large images or minifying CSS or JavaScript files.

6. Don’t Use “Someone Else Built it” as an Excuse

We need to get ourselves out of the habit of writing bad, lazy code because ‘it’s already a mess’. Creating a nightmare project is not something your wider team will want to touch. We’ve all written code we weren’t particularly proud of at some point, often for reasons outside of our control.

We’ve all written code we weren’t particularly proud of…

Tight deadlines, scope creep, and difficult clients are just a few factors that can affect the quality of a site build. Move away from looking for someone to blame and focus on ways you can improve what you have. Always take pride in your work.

The time and effort you put into any site, whether building from scratch or inheriting, pays off in the long term as it creates a readable, maintainable project. You, the team around you and the client will benefit enormously from having a positive attitude towards inherited sites.

So the next time you find yourself having to pick up someone else’s code (before you roll your eyes and start muttering obscenities to yourself) run through these tips and you may just turn a potential nightmare project into a breeze.

Lucy Carter

Lucy Carter is a Web Developer at Stickyeyes and also helps out at a Leeds-based Code Club, teaching children how to code. When she’s not crafting magnificent websites she tends to be climbing big hills.