WORD PTR

Pointed Development

My Biggest Coding Failure

| Comments

You can’t go forward without looking back and you can’t use a less-than when you need a greater-than.

Did I really write that code?!

Back in the early days of my development career, I was responsible for maintaining a secure web site containing certain shipping details of certain carriers. Carriers could only see their own private data, and users were effectively assigned to a single carrier.

A request came in from management which required a small modification to the handling of user authentication and group association.

No big deal.

I made the change, tested and pushed to production.

An hour later I get a panicked call from my manager: “Everyone can see everyone’s data!”

Uh oh.

Nothing squelches hubris like a good old fashioned “You Fucked Up” talk from the president of the company.

Just Change the Code

Let’s turn back the clock to 1999 for a moment. It’s the Wild West era of my development career. The company I worked for didn’t use revision control of any kind. If we wanted to share code, we emailed code blocks to one another. We had no QA: Developers tested themselves. Developers manually deployed to production, and – if we were lucky – maybe deployed to Dev, first. Finally, we were trusting “secure” data to junior developers with no oversight of any kind.

And I thought I was some sort of Software Development Rockstar. That didn’t help.

If only I knew how little I really knew.

The code change I made was innocuous. All I had to do was wrap some method in an if statement, something like this:

if(id <= some_value) { do_something(); }

The problem was, the comparison was backwards. It should have been greater-than-or-equal, not less-than-or-equal.

Pesky inequalities.

I tested my innocuous change and it innocuously worked, apparently. Except I was a Developer signed in to the application as a super-user, and the inequality check was never hit. Did I use a debugger? No. Did I run unit or integration tests? What unit or integration tests? Did I review my code with another developer?

Haha, don’t make me laugh, I’m a “rockstar.”

But hey! It worked! Okay, let’s release it straight to production! Don’t worry about Dev right now, this is “an emergency.”

So I deployed to production and moved on to other problems.

And then the phone call.

That’s about the time the floor dropped out from under my feet and I felt that awful, sinking feeling deep in my stomach, that “I’m a dumbass” feeling. I knew I had screwed up and I knew where I had screwed up and – even worse – I knew it was a mistake caused by nothing more than my own attitude.

My manager runs in, the company president walks in and – to their credit – don’t fire me on the spot. The president asks a few questions about the code change, knods and calmly asks me to fix production as quickly as possible. He then reminds me how bad I had screwed up.

Thanks.

My ego deflated. Permanently.

Growing from Mistakes

This isn’t the only mistake I’ve made during my developer life. Far from it. It’s definitely the worst, though. And it’s not the worst because it opened up a massive security hole in a system. It’s the worst because I made it as a consequence of my own hasty assumptions.

I made it because of my own hubris.

I spent the next several months in deep consideration of my mistake. I spent evenings alternating between being angry and being depressed. Maybe I’m not be cut out to be a developer.

But life goes on.

I made several developer-life-changing decisions during the months and years to follow. They’ve shaped the type of work I do as a developer to this day.

Little by little the Wild West era came to a close and a much more structured and displined approach to development emerged. Revision control became essential. Unit tests became essential. Code reviews became essential. A much more methodical, logical, careful approach to writing code became essential.

Most importantly, my attitude took a back seat: I never was and never will be the Smartest Developer in the room. By making a critical mistake, I discovered the importance of really using my brain, in understanding my own limitations and dedicating my life to learning. I discovered that though I may not be the Smartest Developer, I can be one of the Most Careful Developers. And there’s extraordinary value in slowing down and taking your time.

You can’t go forward without looking back.

Comments