Why Seemingly Small Changes Never Get Made, Or: Technological Debt, Explained

If you were to log into StarCityGames about two years back, you’d have logged in with your username.  And once you’d chosen your username, you could never ever change it.  If you had, in a fit of pique, chosen “SirPoopyhead” as your user name, that was what you’d have to use forever.
The reason you couldn’t change it was because of a silly choice that had been made back in the year 2000, when we’d first purchased our shopping cart software.  The people who had designed that shopping cart decided to use the login name as the unique way of determining who you were – and when we’d created our own customized shopping cart, we hadn’t changed that.  So for all intents and purposes, that arbitrary string of characters – “SirPoopyhead” – was the single factor that made you you.
Problem is, that’s actually terrible design.
See, on the back end of an application, we have literally hundreds of places where we store the answer to the question, “What customer did this?”  What customer placed this order? What customer tried to log in at 4:56:15 am?  What customer ordered a Premium subscription?  What customer has $14.15 in store credit?  And the answer to each of those questions, each answer stored in a separate location, was “SirPoopyhead.”
The problem is that if we changed that string of characters to, say, “SirGalahad,” then we’d have to manually change that string in every one of the hundreds of tables that referenced it.  If we forgot to update just one table (or something went wrong in the middle of all these updates), then somewhere lurking in our database there would be a bunch of records that referenced the now-no-longer existing “SirPoopyhead,” which means that we’d have lost data.  This could be very troubling if we were asking the question, “What customer had paid us money?” when we needed to give you a refund.
And with every new feature we added, this problem got worse.  We added gift certificates, so here’s yet another place we need to store “SirPoopyhead.”  We added wishlists, each of which was duly recorded under “SirPoopyhead.”  Hundreds, thousands, of locations each keyed to this arbitrary string of letters.
Worse, turns out logins are a terrible idea.  Customers forget their logins all the time, having made them up to check out.  If their login was associated with an old email address, they might not even be able to get access to their old login without manual intervention.  We literally had, in some cases, customers who’d created twelve separate accounts because they kept forgetting what their login was supposed to be.
No, what we needed was a nice clean email login like Facebook.  Everybody remembers their emails.  But people change their email addresses a lot – and as noted, having to constantly change “SirPoopyhead@hotmail.com” to something else had a nonzero risk of something going wrong.
What you need, as it turns out, is a unique ID to reference each customer that never changes!  You!  SirPoopyhead!   You’re now customer #123456, and every question we’ll ever ask about you now returns the answer, “Customer #123456.”   Then you can change your email, you can change your login, you can change anything you want – all we’ll be doing is looking up the information for Customer #123456.
But.
But.
Come this point in our shopping cart’s development, we had literally thousands of places in the code that used the login name instead of the customer ID to answer questions.  And it wasn’t as simple as a “search-and-replace”; some of these were complex queries that we’d completely have to rewrite from scratch.  And then, because we’re responsible website owners, we’d want to test all of these changes thoroughly to make sure nothing got broken.
Yet if we wanted to do this, we’d have to do it soon.  Because we were hiring more and more programmers, and adding new features daily, each of which referenced “SirPoopyhead.”  The longer we put this change off, the more places we’d have to change the code.
That’s what’s called technological debt.  Thanks to a bad decision made literally twelve years ago, we had a ton of code that caused us to have to jump through a lot of hoops for what seemed like it should be a simple thing.  And every month that went by without changing this sprawling, underlying code was another month’s worth of updates that would also, eventually, have to be changed.
What followed next was a tedious and gruellng five-week project where I looked through each of the hundreds of thousands of lines of code that touched literally every page on StarCityGames.com, changing instances of “login name” to “customer ID.”  You cannot understand how magnificently boring this was.  There are fun things a programmer can do, usually learning new techniques or doing something flashy – this was basically me, being a smart search-and-replace, doing something a computer wasn’t quite equipped to do.
When it was done, we ran some conversion scripts, and then rolled it out.  Zingo!  To you, the customer, the only change was that there was now a notification saying, “Please log in using your email.”  But to the back end, there was literally a whole new day.
That’s why it’s sometimes hard to change software.  How difficult could it be to change your user name?  Well, as it turns out, thanks to factors that are hard to explain to your average customer, it can be incredibly hard – an unpleasant task requiring weeks to fix, one that adds almost no new features whatsoever, one that can introduce bugs into stable sections of code that haven’t had problems in years…. yet one that ultimately needs to get done in order to make way for bigger changes later on.
That’s why programming is weird.