A Dirty Hack

A client urgently called, asking us to change a message on a page to be worded in a way that was very specific to their context . Their users were viewing it and the change had to go in NOW. This change was very important for the client and it was highly time sensitive.

The problem was that this message was the same across the entire system and was shown under the same conditions to all of the other users. Changing it to what they wanted it to say would make no sense for everyone else.

We were under very tight deadlines and didn’t have the engineering bandwidth or inclination to turn it into a customizable message. Instead of building it appropriately, I made the decision to deploy something similar to the following code:

<div ng-if="client.id == '24217129837'>
   The message text specific to that organization.
</div>
<div ng-if="client.id != '24217129837'>
   The message text everyone else would see.
</div>

The client was satiated, although I was absolutely horrified.

The good news is that we had plans to redesign the entire section — we ended up removing the dirty hack a short time later.

What’s wrong with that?

There’s several things wrong with what I did above. On a purely technical level, it’s looking for a highly specific database record in the view — an area that shouldn’t care at all what specific record it is displaying. The code above would never work on a local development machine or an environment where that client ID didn’t exist. It might even show an incorrect message if it was deployed to another environment.

Ultimately, a quick fix like this one is indicative of a “just get it done” mentality. Hacks like these build up. Unmaintainable applications that hemorrhage money aren’t made overnight — they are made with many tiny, poor changes that at the time don’t seem like such big deals. Eventually, you build up so much technical debt that you can’t get out of it and have to declare bankruptcy. It sneaks up on you, and unless you’re constantly vigilant it will eventually sink your product.

We did the right thing in our situation.

Looking back, we did the right thing in our situation. This was one of our first paying customers for our product, and it was important that we did everything we could to make their experience a good one. First customers are tremendously valuable, and you can learn a huge amount from them. We sure did.

The important thing is that you recognize what you did for what it truly is — a last ditch, emergency, no-other-option effort that is highly damaging to the system. To make a decision like this is a tradeoff that prioritizes the business at significant expense to the system, and steps should be taken to immediately rectify it when able and to put processes in place to ensure it never needs to happen again. The system should serve the business, but the business also needs to ensure that the system survives long enough to serve it. The relationship between the software and the business is a symbiotic relationship, and both need to ensure that the other survives.