If you’re running a business that focuses both on developing solutions from the ground-up or that focuses on implementing a custom solution in the context of pre-existing projects (or maybe both), then you’ve likely – at some point – been in the situation of inheriting WordPress projects.

Tackling projects from either handle brings its set of challenges – most of them welcome  – but it seems to be far more common place for people to complain about working with a pre-existing codebase.

It’s not that I don’t get that feeling, but I do think there’s a level of immaturity in doing that. On the one hand, yes some codebases are outright terrible. But then some codebases aren’t that bad. In fact, I’d argue they are just a little bit different from how you’d develop it.

This is a case in which standards come into play, but I digress on this for now.

So let’s say you’re inheriting WordPress projects and you’re not particularly stoked about the codebase with which you’re working. How is it that you can still enjoy the work that you’re doing without feeling like you need to critique every aspect of whatever it is with which you’re dealing?

Inheriting WordPress Projects

First, this notion of complaining about other people’s work is the proverbial water in which I do not like to tread.

  • I don’t know the background that lead to the codebase to be in its state,
  • I don’t know why certain things were developed they way they were (time constraints, lack familiarity with a project, etc.),
  • I’m tasked with doing something within the context of the project so why spend time focused on things that aren’t part of my responsibility?

I get it: There are times in which we code we write has to communicate with code that already exists. And that can be hard. There are design patterns that aren’t specifically for this situation.

But rather than cover that, I thought I’d share three things that I think show maturity when it comes to development when inheriting WordPress projects that may irritate us.

1. Do Not Refactor Everything

As Martin Fowler as stated:

This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule – always leave the code behind in a better state than you found it.

Generally speaking, I like this rule, but depending on the requirements of the project this may be beyond the purvue of our responsibilities.

Inheriting WordPress Projects: The Codebase

So whenever we come across something that we know needs refactoring but the project is running along smoothly. If you make one change to something because you think it needs to be done, you don’t know how this will cascade throughout the project.

If you have time to do a full audit of the code, that’s one thing, but if not, then your task is to introduce what you’ve agreed to do.

2. Focus on What You Agreed To Do

And that leads into this point: When inheriting WordPress projects, you’re tasked with a certain amount of work and nothing more (that’s why we have a statement of work, right?).

So despite however much you want to change the environment you’re in, don’t. Focus on what you can do, what only you can do, and what you’ve agreed to do.

Inheriting WordPress Projects: The Agreed Upon Word

I think it’s fine to take notes about problems, and I think this can even be beneficial (and I’ll talk about this momentarily), but do not lose focus on what you agreed to do. Doing anything but is unprofessional.

3. Do Not Judge The Previous Developer

Another thing that’s common – especially in open source – is to judge the developer who wrote the initial set of code wit which you’re working.

What is this? I’d never write it that way.

I mean how many times have we thought that to ourselves? But we don’t know the time, constraints, experience, or context in which the developer was working.

The code we release is not necessarily representative of our skill level. It’s often dictated by third-party variables that have influence over the way we implement a solution.

And we know what that’s like, right? How many times have we wanted to do something one way but the constraints and schedule under which we’re working dictate what we’re doing?

So why would we expect those developers to be any different?

Optional: Offer Future Support

As mentioned earlier, if you come across areas in the codebase that are problematic, that doesn’t mean it’s a lost cause.

Instead, when you come across those types of problems, then I think it’s a good idea to:

  • make notes on the things you’ve seen,
  • annotate what you’d do to fix it and why,
  • talk to the customer about what you’ve seen and the advantages to updating it.

This obviously leads to future work but, perhaps above that, it allows you to offer solutions to create better, more well-architected software and it allows you to make sure you’re making the internet a better place for a CMS that’s so popular.

No, this work is never guaranteed, but it’s helpful.

I’m Sure There’s More

These are just three tips that with which I offer based on the experience I have when inheriting WordPress projects. It’s not meant to be all-encompassing.

Instead, it’s meant to provide a few tips that allow you to be more considerate about other people’s work within relation to your work, to think more clearly about what you may do when faced with similar situations, and to garner more work by improving the existing solution potentially.

But I know that the things I’ve mentioned are just a few of my observations. Have your own? Mention them in the comments.