The Hack/Obscenity Lemma

Posted on June 28, 2012

0


CC-by-SA

After working many times in the wee hours of the night, Miller Lite at hand, cleaning/dealing with someone else’s poorly designed shit, I came to an incredible revelation – there exists a quasi-mathematical relationship between an ugly-as-shit hack and its creator. It goes like this:

The structural obscenity magnitude of a hack is exponentially proportional to the fervor and sureness by which its creator believes it superior, better or simpler than a reasonably constructed equivalent – The Hack/Obscenity Lemma.

In plebeian lingo, the shittier the developer, the exponentially shittier his/her evil software spawns are. Scary, I know!!!!!!(10+1) ZOMGLOLCAT!

But first, let’s define what is a hack. It is something done that deviates from an ideal model of software construction.

That on itself is not bad – we should never aim for perfectly constructed software. There are budget constrains, schedule constrains, requirement changes, eventualities impossible to foreseen. In other words, shit happens

… and we get paid to make shit (the good shit) happen, even when shit (the bad shit) happens.

You can tell a good hack (even if it is horrendously constructed) by the way its progenitor documents it.  Typical comments that accompany it range from “we shouldn’t do this, but we ran out of time, re-implement using XY alternative asap”, to “here be dragons” (the later being a sad attempt at humor to placate the creator’s sense of self-disgust.)

In other words, a good hack, however ugly, describes the fact that it is a hack.

More importantly, it explains why it is a hack, its side effects, and what alternatives can be pursued if there is a chance to do so.

Now, what is a repugnant hack, the thing I just described as such in the most negative ways possible?

It is the one where the author is oblivious of the repugnance that stems off it. The one that the author is ignorant of its implications, and its cost to his/her employer. Moreover, it is the offspring, the Chernobyl spawn of an ignorant mind at best, or arrogant mind at worst, who deems it sufficiently good despite all evidence to the contrary.

We have no time for design, code that shit and let’s get moving. This is how we roll.

You, the reader – ever heard these words? Surely you have. Ever uttered them?  God have mercy on your soul.

When you see an ugly hack like that, or more precisely, when you see a preponderance of hacks like that, then you know that the lemma just mentioned describes said progenitor crowd.

There is very little you can do when you work nearby that kind of evil spawns. The only thing you can do is not being like them at all costs.

There is a job, and there is a career.  Program with intent and purpose, with thought. Develop software that sustains itself, and, when necessary hacks that justify their existence.

In the name of everything that is holy, don’t ever let the Hack/Obscenity Lemma apply to you under any circumstances, ever, ever, ever.  I’ll leave you with these parting thoughts imbued in my favorite quote of all. Think of them the next time you write a software abomination:

“When we now take the position that it is not only the programmer’s task to produce a correct program but also to demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer’s activity: the object he has to produce must be usefully structured.” — Edsger Dijkstra

CC-by-SA

Advertisements