We can talk about good code and bad code all day, but it’s important to recognize the other traits of code — other axes on which code can be evaluated.
One of the common ones is the term hacky. What is that?
In some cases, hacky code is meant to run only as a demo, just something ‘hacked together’, like a poet scribbling on the nearest piece of paper she can find. In the programming realm, this proof-of-concept, some early version of an algorithm, often gets picked up as a golden egg and shoved into production. And that’s how you get hacky code in production.
In some ways it’s not far from a literal axe. Hacky code is sharp and yet simple. It is too simple to be used at the industrial scale that is demanded of most programs. Nevertheless, hacky code often contains a nugget of the “optimal” code, or the best code that could be written for the job, and a bunch of crap around it to actually enable it to run.
The nugget of a hacky program is some central analogy, some set of primitives. In many cases, the central analogy can make it all the way from your first prototype to IPO. The first version of the video-making app Vine let you make a 6-second video by recording for the exact time you held your finger on the screen. Let go and the recording stops. And at the end of 6 seconds, the app saves your video to the camera roll and crashes. Vine is long dead now, but this hacky prototype had the killer feature that made Vine great, and did nothing else.
At the intersection of good code and hacky code is elegant code. If you store the data correctly and make the right cuts in features or the data — the “hacky” first attempt can become your trade secret.
Most big companies started with a hacky solution. Twitter’s hack was literally input.truncate(140) in the language it was written in (Ruby). Instagram was an image filtering app. OKCupid was a questionnaire. Reddit started with posts and comments in the same database table.
At its simplest, hacky code is an inspiration, a prototype that gets a key part of the job done at a fraction of the effort.
Calling a piece of code hacky isn’t the same as saying it’s bad, the code just doesn’t have infrastructure around it. You can probably already piece together why they call hackers hackers, and hackathons hackathons — hacks just need to run once. The whole goal of hacking is to succeed once.
By contrast, not hacky code has thorough tests, runs in different environments, and generally supports a team of developers working on it. It’s in a shared repository somewhere, carefully maintained like a zen garden. When your software needs to run for two, three, or ten years… you can reuse some concept from a hacky prototype, but it can’t stay hacky.
—
Thanks for reading. -OP
