Bad Habits

I don’t usually steal posts, but when I do I steal them from foreign language blogs. It’s almost like original content, right? Most of you can’t really read it, so I could probably easily get away with plagiarism this way. But I won’t plagiarize – I will paraphrase and link to source like you’re supposed to.

My excuse for not producing original content is that my weekend was completely taken over by a wedding and a wake (Saturday and Sunday respectively). That’s two days of being social. I am a misanthropic introvert by nature, so social outings are like extreme sports to me – fun in limited quantities, and best when observed from afar. This weekend completely drained my batteries, dulled my wit and dried my creativity. Also I had no time to type up any of my three thousand word epics. I figured I might as well share one of the more entertaining blogs I have been reading lately. If you are fluent (or near fluent) in Polish I highly recommend adding Bronikowski to your RSS feed. He tends to be both funny and insightful at the same time. If you can’t read Polish, let me paraphrase one of his latest posts about bad habits just to give you a taste. Note that my rendition is not nearly as funny as the original.

I promise not to do this too often

Imagine a teenage boy with a dream of becoming a famous bass player. He had everything a young musician would need: passion, musical inclination, impressive collection of CD’s (you know, research) and a wall full of band posters. The only thing he lacked was a guitar. Well, a bass guitar. His father had an old, beaten up acoustic but that instrument was beneath the future rock star.

Sadly, bass guitars turned out to be quite expensive. Our heroes meager allowance was not nearly enough to cover it. He would have to save up for many weeks, maybe even months to afford one. This was of course out of the question. You see, the boy had a burning passion and almost a physical need to express himself through music (on a bass guitar no less). He could not wait. It is of course a known fact that nothing stirs imagination like poverty. The the do-it-yourself spirit has a long and proud tradition that crosses cultural boundaries. In urban regions it is known a “ghetto-rigging” while in the rural areas it is simply redneck inventiveness. Our hero followed this proud tradition and with the help of some power tools, genuine bass strings and liberal application of duct tape he retrofitted his old man’s instrument into a “splendid” makeshift bass guitar. When finished the contraption was far from perfect: the spacing between the strings was all wrong, it could not be properly tuned, and the entire rig was rather unstable and fragile. The aperture would creak pitifully, shift and bend around when he played it. But it was enough to get him started. By the time he saved up enough for a real instrument he would already have all the basics down.

Unfortunately this experiment in extreme guitar makeover did not work out at all. This anecdote may sound like a origins story of some famous musical prodigy, but is not. It is a biographical note of Bronikowski himself – a guy whith ha technology blog who somehow dodged the rockstar fame and fortune. It turns out that making a bass guitar in your garage is not as easy as it may seem. When or hero got his paws on a genuine article he quickly realized that his home-made rig was nothing like it. What is worse, learning to play it did more damage than good. The real instrument behaved very differently, and his technique and timing was off. He learned to play the wrong way – by memorizing tabulatures instead of studying sheet music and using a guitar that was merely a rough approximation of the real thing. The years of plunking away on his makeshift bass were a complete waste. Worse, they were counter productive. Nearly everything he has learned up until that point was wrong. All of it had to be unlearned, and all the habits he formed during his teenage years had to be stomped out just to break even.

The moral of the story is that while instant gratification you get from quick-and-easy hacks makes you feel all warm and gooey inside, it does not usually pay off in the long run. Sometimes it pays of to wait, and do things the right way than to jump into something head first. The home made guitar is like a programming kludge or shortcut you put into your code to save time. Chances are it will bite you in the ass one day – and probably not in the way you would expect it to.

Bronikowski recalls a web application he wrote long time ago. We all have one or two of these – something we wrote straight out of college, and in our eagerness to show off and impress the new boss we cut corners as if we were on Battlestar Galactica. The entire thing turns out to be a collection of kludges, and code snippets copy-pasted from the web, held together by some wonky logic, and duct tape. Somehow, against all odds this shitty app of yours goes into production and doesn’t even crash that often. Hell, you are even kinda proud of it when your boss pats you on the back and tells you you did a good job (he did not read the code obviously). Six months, or maybe even a few years later your app has way more users than you have ever anticipated and all of them want new features. Since you wrote it, you get stuck with updating it. So you sit down, open the source code files and immediately become angry. After 10 minutes of re-familiarizing yourself with the application you are so pissed off that you decide that if a time machine is ever built, you will use it to go back in time and punch yourself in the face six times. Then you rewrite the entire thing from scratch, the right way. Something like this happened to Bronikowski.

In the original version of his intranet web app he did what you would call a lazy field validation. To make sure his users were filling out the required fields, he simply tested whether or not they were empty. It worked well enough in testing (and by testing I mean running the app on your dev machine and going “yeah, looks about right”) and besides – validating email/url fields the right way is fucking hard.

Can you see where this is going? You should never underestimate the laziness of a common office worker. People really do go to great lengths to avoid doing actual work – and if you give them a form without validation they will likely leave every field blank. If you do have validation, but it is not strict, users will quickly find a way around it. One of Bronikowski’s sly coworkers accidentally found out that all the boring required fields will accept a single dash or a single period as a valid input. He passed along this newly acquired trick to all his buddies and within a few weeks it became a deeply entrenched part of common office lore. The side effect was that the reports printed from that application were starting to look more and more like Morse code every week.

Personally I have ran into a similar issue quite a few times. I have dubbed this specific type of user behavior as “N/A in every field syndrome”. It just rolls of the tongue, doesn’t it? Some of my validation logic these days includes a n/a counter which complains if it sees too many.

The powers that be, noticed this slow creep of garbage data filling their database, and tasked our hero with fixing it. He promptly ripped the code apart, updated it and included very strict field validation rules that erred on the side of caution. The new version was thoroughly tested, pampered, polished and then deployed. To everyone’s surprise the update did not go smoothly with the users. The data flow stopped completely, and the help desk phone was ringing of the hook all day.

That first day, users came to work and begun to diligently filling out their forms with rows of dots and dashes, and as little real data as they could get away with. The new system promptly rejected and flagged the invalid fields with clear messages “- is not a valid email”, “- is not a valid web address”, “- is not a number with two decimal points” and etc..

To any logically thinking person, such messages would be fairly clear. This is not a valid input, I guess I have to actually look up real information and plug it in now. To most users however any kind of behavior divergent from what they got used to usually means “Everything is broken, I can’t do my job now, let me call help desk and yell at them at the top of my lungs”. And so they did, in droves. Most would refuse to accept the simple explanation that the system was updated because “it worked for me yesterday”.

This is a perfect example of a situation in which a quick time saving kludge allowed the users to develop bad habits that will now take weeks if not months to stomp out (I see you chuckling over there – you think I’m exaggerating? Go work in end user support for a few weeks, then come back and see if you still think I’m exaggerating). Bronikowski’s users were plying on the home made bass, and when they got upgraded to a proper instrument they became confused and angry. It did not work the same way, and their precious time saving habits could no longer be applied. In their eyes the application became broken, and less user friendly. When you half-ass something you are not just putting off the hard work for later. You might be inadvertently creating much more complex problems down the road – things completely beyond your control, which are impossible to fix with technology alone. Having users come to rely on side-effects of your hackish implementations is something very difficult to predict and very annoying and time consuming to fix.

So don’t cut corners kids. Do it right the first time, or else your users will figure out a way to punish you for your laziness somehow.