Editor’s note: This article was first written in 2017. While certain technical specifics are now passé, the principles outlined here remain solid… TLDR: the complex, disparate practice of codebase maintenance make it highly resistant to efficient outsourcing.
I coded before I became a manager, and managed internal teams before I became an agency client. I naively imagined that having an agency manage our website would make my job easier. It did not.
Imagine making yourself a cup of tea, just the way you like it.
Now imagine asking someone else to make you a similar cup of tea. Subjectively it’s probably not quite as good, but objectively it might even be better. Plus you didn’t have to do it yourself.
Next, imagine writing a detailed set of instructions on how to make a cup of tea (just the way you like it) for someone who is super nice but has absolutely no idea what tea is. We’ll call that person the Account Manager. The Account Manager passes off these instructions to a Project Manager, who examines their scheduling software to determine when one of their specialist tea makers might have a window to evaluate the request. The next day the specialist estimates that it would ordinarily take them five minutes; however they aren’t familiar with this particular brand of tea, so they’ll need another five minutes to confirm how to steep this tea properly; plus another fifteen minutes to find all the tea-making materials and put them away again afterwards. The system only records in half-hour increments, so that’s a half-hour. The PM then factors in QA to ensure that the produced tea matches the request, and their own time to coordinate it. So it’ll take 90 minutes at $200/hour, thus $300… if produced as part of the next tea-making release, which is scheduled for next quarter. If you actually need that cup of tea this week, they will have to take the specialist off-task and charge this as a rush-job at 150%. So, $450 gets you tea on Thursday by close of business. Note that $450 does not include your time describing your tea needs in writing and, in due course, confirming that the correct tea was delivered to specification. Or processing their invoice.
If you’ve never made a cup of tea, have no interest in learning, could really do with a cup of tea, can wait until Thursday and have money to burn, well, this is simply the cost of tea. On the other hand, if paying $450 for a cup of tea would have you convening your friends for an impromptu party in Boston harbor, I can sympathize. It is very hard to accept that $450 is a fair price. And yet, it is the cost of doing business. It’s just a business that cannot be outsourced efficiently using traditional agency models.
There are a multitude of everyday digital marketing tasks that can be efficiently outsourced. Community management, routine content maintenance and SEM are all good candidates. These are well-defined, repeatable, detail-oriented and time-consuming activities which often demand specific expertise. For each, it’s possible to agree on an approach and let an agency run with it, merely checking in from time to time to evaluate performance. Once trust has developed, you can even begin to relax about this or that activity, knowing it’s in safe hands. This allows you to focus your attention elsewhere, back at the 30,000 foot level or some such, where you belong.
Note that I’m talking specifically about routine tasks. By contrast, it is often logical to outsource project work, including actual web development i.e. the production of brand new websites or major new areas of functionality. Projects get finished, after all, and it’s frequently unwise to staff up to meet ephemeral needs.
Production websites, however, are so much more, well, fiddly…
For example, not too long ago, our ridiculously talented and seriously overworked editor submitted three tickets relating to the way bylines are displayed in articles on our website. They amounted to a) not displaying an updated date for an article if it matched the published date, b) displaying the word “updated” in lowercase and c) formatting months according to our style guide, as detailed below –
The estimated development and QA costs to resolve these tickets came back at $1,187.50. Now, our site gets a lot of traffic, and I have been told that consistent grammar is important. At the same time, I couldn’t help but feel that there are better, more impactful ways to spend a thousand dollars.
I’m really not supposed to be coding anymore — I’m supposed to be managing and directing, filing TPS reports, “imagineering” and so forth. But for the sake of a grand, I find myself spinning up Visual Studio Code and taking a hack at it.
Addressing the issues myself took about 45 minutes.
Nerdy interlude explaining how I did it
<nerdy>I discovered four templates which contained identical byline date code. I toyed with the idea of abstracting them into a function, but hey, it had clearly been this way for a while and changing it might confuse others and possibly introduce new bugs, so I fell back on copy-and-paste. I wrote a short function to translate months into our special format. I wrapped the date display strings in that, deleted the hardcoded uppercase “U” in “Updated,” replaced it with a lowercase one — and added a clause to only display the modified date if it didn’t match the created date. All of that took longer to write just now in English than it did in php. I also discovered that our micro-formatted dates did not follow the schema.org spec, so I fixed that while I was there. It took a few minutes to verify the specification and remind myself of php’s date formatting functions. I tested my changes locally and then on dev. The whole deal would have been even quicker, but checking code out of and into our repository took way longer than it ought to have done because I’m absolutely rubbish with git.</nerdy>
How do we get to the point where 45 minutes of (ageing internal) developer time, when pushed instead through the pipeline of a competent agency, transmutes into nearly $1,200 of billable hours (plus, say, an hour of internal management overhead)?
First, let’s be clear here about what the problem isn’t. It’s not the agency. The staff are highly capable, they listen, and are completely transparent as to how hours are allocated. I do not suspect for one second that anything is padded. It’s actually a pleasure to work with them.
It’s the nature of the work itself. Specifically…
1. Software maintenance is a Sisyphean, janitorial exercise. All of the glamour, plaudits and perhaps as much as 25% of the overall lifecycle costs (as well as much of the creativity and fun), go into site development. Meanwhile, maintaining the codebase, by which I mean fixing emergent bugs and adapting the site to emergent needs, takes up the lion’s share of web “development” work. It’s painstaking, complex and untidy, and much of it takes place beneath the radar of users and non-technical management whose familiarity with the product rarely probes beyond, “does it look good?” and “is it broken?”
A cursory scan through the last 100 or so tickets in our issue tracker imparts the flavor: implementation and subsequent tweaking of Accelerated Mobile Pages, styling updates to support a marketing campaign, a fix for a “share” link that didn’t work in the latest version of Firefox, fixes relating to changes in coupled third party code (an outdated SSL certificate, a change in Captcha implementation, a new look for an embedded form), performance tweaks to our cache configuration, upgrading to a more recent version of php, tweaking our metadata to better match Facebook and Schema.org’s evolving standards etc.
Making changes efficiently, without introducing new errors, requires deep familiarity with the codebase. Robert Glass’ Fact #44 of software engineering is that the dominant maintenance activity is understanding the existing product. That’s hard to achieve as an agency developer, because a) you’re in a polyamorous relationship with multiple different codebases and it’s really hard to remember all those codebases’ idiosyncrasies, b) agency churn often makes these liaisons short lived, which in turn leads to c) too many cooks in the codebase, each with their own style and level of commitment to coding and commenting standards. As Joel Spolsky observes, it’s far harder to read code than it is to write it, and you need to read many lines of other people’s code before you start tinkering with them. Sure, near-standardization on WordPress and Drupal in the CMS universe has significantly flattened the learning curve, but all websites at scale have significant customizations above and beyond their core.
2. The telephone game. Between the person requesting a change to the website, and their sign-off that the task has been completed to their satisfaction, there exists a long chain of specialists. In our case, there is the internal technical point of contact that distills the request into a standard ticket, a PM at the agency that receives the ticket and passes it to a developer and/or designer for estimation and execution, and a QA expert to examine functionality following code check-in. Tickets move back and forth along the chain. For clearly defined, labor-intensive tasks, such processes need not be onerous; that entire management overhead is no more than the frothy head atop the wholesome pint of English bitter that is the execution.
If I asked a caterer to produce 1,000 identical cupcakes, for example, I’m sure there’d be some discussion and paperwork involved; but filing that invoice is definitely going to take less time than it would take the bakers to bake the cakes, let alone how long it might take me to do the same. Web maintenance is pretty much the opposite of this — you’re making 1,000 different custom cupcakes for 1,000 different people and there’s a lot of back-and-forth throughout the baking process because the person ordering the cupcakes isn’t exactly sure what kind of cupcake everyone wants and the baker has to ensure that each cupcake is not only delicious and beautiful on its own merits, but that it coheres with all the other pastries in their window display. Also, the baker only speaks French, and it turns out that the requestor actually wanted an éclairs.
In the example of the byline tickets described earlier, they’d been cumulatively passed 18 times and had attracted 13 comments before they got to me. Every handoff accumulates minutes and inserts a delay. And yet that communication is necessary, because so much can be lost in translation between technical and non-technical staff. Without communication, the product is almost always just a parodic interpretation of nebulous intents. Tickets, screenshots, Slack messages and conference calls codify and clarify issues, closing the gap, very, very expensively.
Alternatively you could sit a developer next to your product manager, have them communicate and iterate in real time, in real life, and save a whole lot of hours and confusion and potential for confusion.
That then, is the gist of it. The motley nature of website maintenance just makes it a very poor fit for outsourcing. It takes more staff time to manage a third party to perform the task than to actually perform the task, and it costs a vast amount of money, because developers are necessarily more distant from the code and communication overheads absorb hours. Both provide additional leeway for the introduction of new errors and cascading costs.
In a nutshell: it’s either make a nice cup of tea at your office, or spend your time on the phone ordering in a very, very expensive cup of cold tea for next Thursday.
Leave a Reply