Inheriting WordPress Projects: Tips For Development

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.

2 Replies to “Inheriting WordPress Projects: Tips For Development”

  1. It’s a good thing I read this yesterday, because I found myself confronting the problem from the other side. I’m still subscribed to notifications from a client’s GitHub repository, and suddenly got a list of commits from the maintenance people.

    My first thought was “WTF are you doing with my code?!?!” That would be a terrible thing to say to either the client or the person making the commits. I wasn’t privy to whatever conversations led to those changes and it’s really not my business. If they’d wanted my opinion, they would have asked for it.

  2. I strongly agree with #3. Let they who has never been put into a position to deliver bad code throw the first stone.

    That said, I do not think it is immature to identify the current state of the code as being problematic, and there are objective measures by which refactoring can be required. Specifically code needs to be refactored when the code makes it difficult to add or change something without breaking a lot of unrelated areas of the project. These can include:

    Conventions applied very inconsistently, no apparent conventions used at all.
    Widespread duplication of logic and magic numbers (VERY common in WordPress themes)
    Naming of functions, variables, classes and or methods that do not convey sufficient meaning when used in complex code
    Inconsistent usage of data types in complex code such that you are never sure what certain variables contain or functions/methods return.

    I am sure there is more, but I typically find those to be the most troubling.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.