It’s a Dirty Word
I debated whether or not to write this blog. I like to offer something positive in my writing (generally) and wasn’t sure if I could bring this topic around. But it is an issue that I have run into time after time year after year. So I decided to go for it.
Usually the scenario I run into is something like this:
I encounter a stranger, either in a bar or event or other social setting. We exchange pleasantries, which usually includes revealing professions.
“So you make websites?” they ask as their brows raise hopefully.
“Yes,” I usually take a drink to brace for what’s coming next.
“Hey, maybe you can help me with a website!?” they declare more than request.
“Maybe,” I usually say hesitantly. But I appreciate entrepreneurship and maybe they’ve thought up the next big thing. “What do you need built?”
“Oh no no no,” they invariably correct. “I already had my (nephew / friend / vendor) build me a site. I need changes made to it. Simple stuff. Really straight-forward.”
“Oh?” I take another drink. “Where is your (nephew / friend / vendor) now?”
This is where it gets interesting. They usually have a perfectly plausible excuse: moved to college, too busy, won’t return calls, etc.
I hate to be that guy who makes assumptions. But if it really is “simple stuff” the original builder would handle it—right? I mean, the Internet is everywhere. It’s at college. It’s there on the weekend. So at least a couple of those excuses fall apart a little.
The “won’t return calls” explanation also makes me feel like a bad person. Because I have to wonder how the relationship came to that? Was the developer just a total assh*le out to steal money and blow town? Or are the issues on the client?
Reality is usually somewhere in the middle.
That’s where the L-word comes in. And that’s where I hope to be an advocate for both client and vendor from this point forward.
What’s the “L-word” I keep mentioning?
When approaching a new developer with an existing website or codebase, you should go in with a few things in mind:
Time for An Estimate
They’re going to have a hard time estimating their work without taking a deep look at what already exists. This may mean you have to pay them to even give you an estimate. You may think they can just roll that into the bill after they finish, but what if they spend 4 hours to get back to you and then you pass?
You should definitely get a written summary of the issues from the developer before you pay them. This way you have something to shop around if you think you know someone who will do it cheaper.
Simple Isn’t Always Simple
A huge problem with legacy code, is that in many programming languages there is more than one way to accomplish a thing. Your old developer may have run very far in one direction, and your new developer would have never set it up like that. Keep in mind that things that often look “simple” or “straightforward” may be the tip of an iceberg.
Don’t Estimate, Testimate
I don’t take on legacy work without getting the code, creating a local version, and making several basic test changes just to see how things work and be sure there’s nothing weird that crops up. Make sure your client is ok paying for that time no matter what.
I follow a checklist for WordPress sites that goes something like this:
- add menu items
- remove menu items
- update the home page
- add something to the header and footer
- check the forms
- make sure all plugins are updated
- and run through everything that looks dynamic on the site
- trust nothing – make sure you can do things before you promise anything
This gauntlet should reveal any weirdness. It also takes a couple hours to accomplish—even if everything is super sweet.
Part 1 of your proposal should be noting any issues that came up during your code review. How much detail do you need? A reasonable amount. You don’t need to write everything in jargon. You can write in regular English and cite names of files or functions that are issues. Just put yourself in the shoes of the next developer the client may go to. What would you want to know ahead of time?
Part 2 of your proposal should explain what the client is getting (their feature/functionality requests) for your estimated cost . I totally understand that it’s not practical, and sometimes not even possible, to line-item everything. But come as close as you can. Purchasers of services almost always accept the costs more easily when you define where the money is going. If items are interrelated, bundle them in the estimate as well.
That’s it. Never be burned by a legacy project ever again.
If you are someone who had someone else build you a website, and now they aren’t around and you need another someone else to do more work on it—understand that you may have to invest a little money just to get your site looked at.
If you are a site-builder approached by someone with legacy code, give it a chance—as long as they’re willing to pay you for a thorough site review and estimate. That shows they’re serious and appreciate your time. Which is a good sign.