17
Hacks Are Fine
This essay has been adapted from a lightning talk that I originally presented to coworkers in 2019. It was intended as an absurd, tongue-in-cheek thought experiment, but I'd like to think there could possibly be some truth to it...
There's a slight problem with the standard definition of a hack. It says more about why you wouldn't want to use one than why you might. What if—now hear me out—hacks are fine?
A "hack" (also known as a "kludge") is defined by Wikipedia as:
A solution to a problem, the performance of a task, or a system fix which is inefficient, inelegant ("hacky"), or even incomprehensible, but which somehow works.
A definition like this will prime readers a certain way by using more negative words than positive. Also, that little bit of bewilderment at the very end really gets me—somehow hacks work!?! Gosh! My goodness!
So, let's consider several reasons why we maybe shouldn't be surprised by hacks as viable, successful solutions.
Hacks can be exciting! Nobody wants a protagonist who has all the time and resources they need at their disposal. That's not good storytelling. Just ask MacGyver here.
Now, I'm only half-joking. You could find yourself working for a company, or on a particular project, where you don't have all of the resources or support you'll need to be effective.
This will force you to get creative and think outside the box. And after a few such challenges in your career, you'll be a better developer because of it.
When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.
And sometimes you just have to ship it, even for production code. There's often a deadline, at which point nobody really cares that you're a code poet. A hack could be the path of least resistance.
A certain amount of technical or product debt isn't, in and of itself, a bad thing. It's an artifact of a decision that was made to get to an end result. It's evidence of a compromise that was made, or a trade-off that (I hope!) was carefully weighed.
How you track that debt and pay it down is another question, of course...
Speaking of trade-offs, hacks are an opportunity for critical thinking. A responsible hack means you've considered things like cost versus benefit or risk versus reward. This is actually a very important learned skill over time.
At the very least, in the short-term a hack might shake loose the ideal solution to a problem you've been struggling with all day. You'll think about it when you go home that evening and maybe even lose some sleep over it. But, in mulling over the hack you'd really prefer to avoid in the morning, you just might come back with a better solution!
You also need to consider the likelihood that You Aren't Gonna Need It (a.k.a. YAGNI). A simpler solution is almost always the better solution, if you can pull it off. Sometimes that might feel like a hack.
I can't be sure, but I think Ron Jeffries might be against premature implementation:
Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them.
Trying to predict the future of your code is ambitious. The odds are low that you'll end up being correct. So, it might be more prudent to hedge your bets with a conservative stop-gap measure that costs you less up front.
In a similar vein, very little of your hard work will live forever. Software can have a very short shelf life whether it's due to redesigns, refactors, business closures or acquisitions, startup pivots, and so on.
I once did some quick math on a napkin and surveyed my previous 9 jobs going all the way back to the late 90s. It's probable that only about 20% of anything I'd ever worked on still existed. Obviously, output from my very first job is gone—so long, Coldfusion!—but so is stuff I worked on just a few years before.
The point being, if perhaps there's a hack in production that you're really not proud of you might not have to worry for very long!
On the other hand, your hack could last a lifetime.
If that hacky code is working and delivering value then you've created legacy code. Congratulations!
But if that hack doesn't work perfectly, well, I still wouldn't worry much. We can all think of that bug, maintenance task, or tech debt issue that sits in a Jira backlog for months or even years, right? A codebase will always have issues that ultimately never get looked at, which raises the question: if you never fix it, was it ever broken?
I Am Devloper@iamdevloper
i fear i’ll be on my deathbed and Jira will still be sending me emails about bugs assigned to me13:14 PM - 19 Aug 2014
For instance, I can tell you that one of Canada's most popular websites contains a self-identified hack that's been executed by hundreds of thousands of visitors daily for at least 7 years and counting.
For fun, I recommend searching for terms like hack or FIXME hidden in the comments of your codebases and see what you find.
Speaking of durable hacks, we can broaden the original defintion beyond just software. We're surrounded by many hacks which we take for granted every day.
Advances in science and engineering often progress by way of hacks. The Apollo moon landings are a great example—to get to the moon we literally threw away an entire Saturn V rocket every time. Oh, and if you expected to come home you had to crash a tiny module into the ocean and be rescued. And yet, there are footprints on the moon!
And let's not forget what a central processing unit (CPU) truly is:
daisyowl@daisyowlif you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking00:03 AM - 15 Mar 2017
The scientific theory of evolution by natural selection is the ultimate hack. Evolution does not prematurely optimize! Natural selection works with whatever's at hand and the smallest change that works well enough is the winner. You, reading this right now, are the result of an innumerable series of tiny hacks.
That said, the human body is still a hot mess:
- Our eyes are wired backwards.
- Our spines were never meant to be vertical.
- We put food and air down the same hole.
And then there's childbirth. The pelvis and birth canal are narrow because we grew to enjoy walking on 2 feet. However, our brains are also big and, like, really smart. So, babies come out when they do because their heads wouldn't fit if they waited any longer! Babies also have soft skulls to facilitate this, and can only come out head-first and facing backwards. Consequently, newborns still develop as if they're in the womb—the so-called 4th trimester.
Sorry! That was a bit of a tangent.
If you employ a hack, don't be so ashamed. Don't be too proud, either. Above all, don't be lazy—be certain and deliberate about why you're using a hack. Remember there are times you shouldn't use a hack (i.e., extending or tacking onto an existing hack).
If you discover a hack, try to reserve judgement. Consider why it might be there... Is the developer going for a moon shot? Do they think they're MacGyver? Is YAGNI a consideration? Use the hack as an opportunity for dialogue and empathic code review.
So, I guess I'm ultimately pleading for ambivalence and nuance—hacks can be evil, lazy, clever, useful, or anything in between. Hacks are just... fine. But since hacks are all around us, and constantly so, it's to our benefit to accept their utility and consider them an essential skill in any developer's bag of tricks. Maybe.
Images, in order of appearance, are courtesy of Darius Soodmand and xkcd.
17