Greenfield projects are the dream of most of developers. We have no legacy code to deal with. Just a clean WordPress install and whatever tools we decide best accomplish the goals of the client.
Unfortunately you’re not always going to get greenfield projects. Some will have legacy code that you have to accommodate and you may even be getting a repair job where the legacy code is just busted.
Here’s how I approach a client project that has legacy issues.
Review Review Review
It’s pretty typical for a client to know what the issues are with their site. You’ll get a list like:
- infinite redirect loop on category pages
- super slow when I view the homepage
- I have no idea why we are getting post content on my sidebar on X page.
I’ve got a starting point sure, but I don’t have any idea why those things are happening either. I haven’t seen the code and I probably don’t know who built the site and the type of code they write (it’s all bad if you didn’t write it right!). The best I’ve got is a guess about why it might be happening and you can’t quote fixes on a guess.
That means the starting point is a site/code review. For my clients I book in a 5 – 10 hour review with the goal of determining why the issues they’ve highlighted are happening and what it’s going to take to fix it.
My reviews have 3 main categories that roughly follow below (but with more client friendly names).
- Urgent as in the internet will blow up and you will be hacked
- Important but not any impending issues that I see
- I dislike it, but there is nothing wrong with this approach I guess
Items like not equeueing javascript properly or using query_posts I put in “Urgent”, and things like using deprecated functions in “Important”. Relying on a plugin that’s not as solid as other offerings (like not using Gravity Forms) is my third priority item.
How I review
For themes I follow the basic theme review process. That’s going to at least give you a baseline to judge overall quality and usually point you in the right direction for the next step, manual review of the files.
After going through all the automated stuff I then manually review every file in the theme looking for best practices. If I find things that are not best practice then those go in the report.
Once I’ve gone through the theme I move on to plugins. If the site has well known plugins (WooCommerce, EDD, Gravity Forms) I simply make sure that they haven’t been ‘hacked’ to achieve some site function and are running their most current version.
If they have been modified then I add to my report what’s necessary in a separate plugin to achieve the functionality without modifying the primary plugin.
Then I try to pick off the ‘culprits’ I’ve seen cause site issues. Almost any related posts plugin is going to bring a site to it’s knees in a puddle of tears. Social plugins are also often super slow since they call scripts from the social network and that leaves you relying on the social network to provide the scripts quickly.
Finally, if I haven’t heard of a plugin that’s in use, I do some research on it. That means a tweet asking if anyone I trust has heard of it and some research on the WordPress plugin repository. I’m basically looking for a plugin that has been updated recently (so we’re not stuck with legacy code that’s just getting older) and then I do a code review of it.
Quoting the work
Well we’ve now become very familiar with code that has a shady legacy and it’s time to get the client an estimate on the cost to bring everything up to the quality desired.
Each line item has in it an estimated cost to fix the issue and a line or two on how it will be accomplished. I tell all my clients that they are free to take that report to whomever they want and get them to do the work. I’ve only once had a client take the work elsewhere and they were back in a few months with a few issues fixed, and more issues to be addressed.
I absolutely don’t believe in holding my cards close to encourage client lock in. If that’s how you keep your business afloat, you’re _doing_it_wrong.
A very important thing to remember is that you need padding in those times. I 100% promise that you will find something else that is a dependancy of the work you quoted that needs to be added to the list. No client is going to be happy that you keep coming back saying ‘just one more thing’. That bit of padding gives you room to tackle an extra thing or two for the client. Even better is that you can let them know and just say that there was a bit of extra room and you did it.
Their bill is the same and you are a rock star.
Deploy often
Finally you need to deploy often to really test things. I pick the top priority item on the list and fix it and deploy it. If you can do it in a day or less, even better. That’s going to show the client that you’re making progress and it’s going to get their site running better fast.
Fixing everything and not saying anything to the client until it’s all done is a sure fire way for them to think they are getting screwed. Lets face it, it’s pretty likely that they already feel a bit screwed with the “crappy” site they got the first time. They’re going to be ready to assume the worst so you need to get in there and give them over the top service for them to think that it’s just okay.
“Wait” you say: “Over the top service? None of this is my fault. Sounds like a high maintenance client.”
I don’t disagree with you at all. They are going to start high maintenance because they’ve been screwed before. Once you establish that you are super concerned about their business and moving it forward, they’re going to be awesome most of the time.
They’ve already established that they have money to pay since they came to you to fix things after paying someone else. They’re just scared at first and you’re going to teach them that not all developers are bad.
That’s a wrap
So the short version is:
- Review the site in detail and charge for it
- Produce a fairly detailed report with time/cost on it and group things in terms of priority for their site
- Deploy often as part of giving super amazing service to the client
I’ve got a bunch of clients that started as rescue projects years ago. We now work together regularly on great projects because I put so much time in to them when they were “high maintenance”. It was totally worth it.
[poststatus-author-bio]
Great approach! Very similar to what I like to do, but I hadn’t placed as much emphasis on the “deploy often” stance … that’s going to change!
Great Article. I love the charging for the review and will implement that. I recently was asked to quote for a WordPress theme amend so I went through the theme code and quoted based on what I found and what needed doing. I didn’t get the gig and wasted my time on a client more interested get the lowest price over quality work 😉
I’ve done the same thing now. Identifying the issues is just as important (and payable) as fixing them.
so what’s the big negative of using query_posts?
Best resource on why query_posts is a bad idea can be found at the link below.
http://developer.wordpress.com/2012/05/14/querying-posts-without-query_posts/
Great run through, a hard lesson that all developers will learn is that quoting for work accordingly is a big thing, never under quote for quality work, get paid for the time that you spend on a project!
Great, practical advice, that discusses real implementation details. We need more articles like this, and a lot less “fluff” articles that so many other bloggers churn out.
I’ll try not to contribute to the fluff.
If you have any other specific questions you can get in touch with me on my personal site.
Have a great day.