by Kate Daly

11 Oct 2015

Technical Debt: More than Just Code

Wow, I’d thought, walking away from the first meeting. They really need some help. 

Their situation didn’t surprise me. It’s a story most of us have heard time and time again: A business adopts a technology, the system is poorly implemented in one way or customized in several, power struggles over ownership complicate communication, and the company limps along with these injuries for years. 

Where did it all start, and how did it get so bad?

We want a website! When do we want it? Now!

I figure it was around the mid-to-late 90s when Boards of Directors everywhere were forced to stop ignoring that “Company Internet Page” agenda item and finally take action. 

So they registered a domain name, sent somebody from the public relations team to Microsoft FrontPage training, and put up a one-pager with the company logo at the top, a horizontal rule, and a bunch of Times New Roman after that. 

Many of these companies eventually adopted primitive content management systems, but several failed to use them to their full capacity, and in most cases, not even correctly. At one of my first jobs, the company had a CMS, but couldn’t “M” the “C” in it very well because every page was just one giant-ass text field filled with HTML tags and inline styles.

The system was used by the publishing team, maintained by the IT team, and abused by everyone. (No one had had proper training, either.) I was eventually tasked with working in it, and my favorite atrocity was — on the homepage — finding the text “nbsp,” surrounded by white font tags, repeated several times over to create some white space between two article blurbs. 

Eventually the company dumped that CMS and got another one, but things didn’t improve.

It’s Mine. No, it’s MINE.

Things did start to mature, though, and around the “let’s have a fixed-width site with really tiny Arial font” wave of 2003, places were starting to train their developers in classic ASP and put out some simple data-driven programs for the web. The majority of these devs had only worked on grey desktop applications for internal processes — a timesheet app, or maybe one that made minor edits in the company’s customer database — and the battle for website ownership began.

At the place where I worked, the publishing team — the writers, and in our case, the folks with design skills — were suddenly told to “sit back and shut up” while the IT team selected (with very little concern for the actual needs of the other team), implemented (with seemingly no care for workflow), and controlled the content that went on the web.

Want something on the website? Send it to the IT team. They’ll decide what gets published.

Find a bug? Get in line, sister.

Need something on the website, like now, because it’s actually serious, not simply something I forgot, not “just-me” important, but “it affects our whole company” important. Well, maybe if you planned ahead more, like we do here in IT, this wouldn’t happen.

I once overheard two IT guys discussing the “absurd” request they’d gotten from marketing to kindly please have the ability to publish their own content. “Are they serious?” one had remarked. “I mean, they could just go and write ‘Fuck you’ on the homepage.”

I was an “IT guy” myself at the time, and knew the marketing team would save their “Fuck yous” for something else.

PDFs for Everyone!

Despite the IT team’s focus on control and ability to click the “publish” button, and despite the marketing team’s focus on creation of content, no one seemed to really worry about the quality or quantity of the content. 

Pages were created at break-neck pace. Everything, everything, everything the company published on paper — from journals to newsletters to flyers — was put out on the website. Microsites were created for every event, no matter how small. Vanity URLs appeared on stickers and buttons and magnets. Redirects to redirects were the norm.

The site had a tertiary nav that grew to a quaternary nav that grew to a quinary nav that usually had only one page under it. The site exploded with PDFs. Can’t find where it should go? Make it a PDF. No time to create a page in that beast CMS? PDF it is. 

I once asked who the site’s audience was. The answer? “The world!”

Rise of the Homegrown

As customers started to expect more and more functionality beyond static pages, companies were faced with a new problem: Finding an off-the-shelf program that did what they needed or writing one internally from scratch. 

Although many made noble attempts not to “reinvent the wheel,” their company’s need most often proved to be a very special snowflake for which no out-of-the-box system could suffice. 

Enter the homegrown system.

Homegrown systems, many developed as long as a decade ago, still live on in companies today. These legacy systems often took years to develop, were QA’d by the same guy who wrote them, and are referred to internally by the developer’s name. (“I dunno, that’s Bob’s app. If you have a question, you just send him an email.”) 

Oftentimes, “Bob’s app” has become so intertwined with a company’s processes that the idea of replacing it, even with a widely adopted and community-vetted OOTB program that does nearly the same thing, seems impossibly daunting.

Highly customized systems are no different. If a company did make the decision to purchase instead of writing a system internally, task number one was usually to customize it to account for the 10% or so of special functionality the company needed. 

Instead of working to change the internal process to adapt to what would be different, many places customized the fuck out of these systems, year after year, making any chance of upgrade impossible.

Documentation? Not on my watch.

Bob, the guy who wrote that app? He’s a nice guy. In fact, he’s a super-nice guy. Bob will answer your questions and not be a dick. Bob might even take your idea for an improvement and do it!

Bob, man, he’s the guy. 

But what Bob isn’t very good at, maybe because no one ever asked him to (but more likely because there wasn’t any time for it), is documenting whatever the fuck is going on in his app.

Bob doesn’t just not document his code — he’s the only one who works on it, so why bother? — he’s never written anything about what it does, how he changed it back in ‘09, or the third-party dependencies it has.

So when a company’s Bob leaves, as Bobs often do, they’re SOL.

Don’t Click That

Some places do have documentation, though. In fact, I once heard of a company that had an 80-page user guide. Problem was that the giant user guide was for their customer-facing eCommerce system. 

If a new user wanted to transact on the system, they needed to fill out the online form, wait 3 days for a customer service rep to hand-key them into multiple disconnected databases, wait for a confirmation email, and then schedule a training session with the one person in the company who knew how to train users on the how to buy something. 

The site was so complex, so tailored to the needs of the company’s internal systems, that a user off the street would be helpless if they tried to do anything. The idea of designing the system to work for the needs of its external audience was the farthest thing from their minds.

A New Hope

To borrow a phrase from a friend, and one I’ve heard repeated many times throughout my career, is that companies sometimes can’t get out of their own way. Their websites sprang up from a need to have a website, not necessarily as a way to actually meet their customers’ needs. 

In everything from terminology to functionality, serving the internal needs of the business came first — and for some, it’s still that way. Thousands of companies — even those with household names — are paying developers and designers to stamp out the smoldering fires of the past, so much so that focusing on the future becomes lower and lower priority. 

So many of the people working at these companies are tired. Tired of dealing with the bullshit, tired of the customer complaints, tired of the look their friends give them when they pull up the site on an iPhone. They’re convinced their company is the only one still operating this way. Their systems are full of technical debt — and emotional debt as well. 

They know things have to change.

That’s where we come in. We’ve been down these roads before, and we know the way out. And as we look into the frustrated faces of the people seeking our help, we can nod, listen — and assure them that they’re not alone.

Dive Deeper

If you want to know more about the Pastry Box Project, you can read about the genesis (and goals) of the project.

Swim In The Stream

A stream of all the thoughts published on the Pastry Box Project is available. Keep it open somewhere, and lose yourself in it whenever you feel like it.

Meet Your Host

There are not only pieces of software talking to each other behind this website. There is a human, too. The Pastry Box is brought to you by Alex Duloz.

Stay Tuned

You can follow @thepastrybox on Twitter. For direct inquiries, get in touch with @alexduloz.