The Right Thing to Do isn’t always The Right Thing to Do

The current way of doing things leaves us wide open to a SQL injection attack. -Andrew

I work with this guy who is called Andrew. He tends to be very thorough, and has a valuable, but often annoying habit of finding subtle inconsistencies in our software. Often times he laughs, I turn to see him smiling ear-to-ear, and he proclaims with great pride that he’s found a potential bug in the software. He derives great amusement from this every time. He’s been known to laugh, remove his headphones, and declare, “Haha! I found a bug! I don’t see how this could ever have worked!!” And it gets under my skin every time, because I’m the one who probably wrote that piece of code that’s giving him some twisted form of pleasure, and I’ve already predetermined that somehow, someone else broke it.

Personal egos aside, these are scary words to hear. In this particular instance, he’s pointed out an area of our software in which we could be susceptible to a SQL injection attack.

Is It Worth It?

We take pride in our software, and something like this hits me in the center of my idealistic core. Alarms are going off in my head, and my heart rate increases. My initial thought is, “Let’s drop everything and fix it.” But then I take a step back. This vulnerability exists in one place, in a very specific, very unlikely scenario. And, we’re also talking about a very secure application that is exposed to only users with proper credentials to access. And, in order to fix this vulnerability, we’d have to spend a week rewriting a bunch of pieces of code just to close up this one tiny hole. We ask ourselves, “Is it worth it?”

I tend to be an idealist about the design of software I work on. My team and I work in a very fast-paced environment, and we often come across areas of the software which we believe should work differently. We discuss the Right Thing to Do and come to a conclusion of a much grander, much more flexible design. But then we always have to step back and ask ourselves, “Is it worth it?”

Software that Works

At the end of the day, what really matters is that we deliver software that works. Security, of course, is of paramount importance. Maintainability and beauty of the code is important and necessary, but in my experience, most of the time we just don’t have time to redesign and rewrite things to be as they “should” be. We’d be making a better code base, yes, but do our customers really notice or even care? No. If our team spends 6 months making all the code “Right”, and then made the software available to our customers, why would they upgrade? They would ask “What are the new features?” We could only say, “Well, we rewrote the back-end of a couple of our reports, re-factored a bunch of business logic classes, and changed a bunch of our icons to use these things called ‘sprites’ instead.” Big deal. Nobody’s going to upgrade the software if there are no measurable benefits. That would be 6 months wasted. 6 months during which the competition gets ahead of us.

I would say there are different levels of “acceptability” as follows:

• Unacceptable
• Acceptable
• Good
• Perfect

The Law of Diminishing Returns is in full effect here. The key is to define which pieces of the software fall in the “Unacceptable” category, and address those problems the best you can, while still adding customer-perceived value to the software. It’s definitely a tricky thing to do. It can go against your idealistic tendencies. It can cause heated arguments among product managers and developers. You have to remember that if all you do is go around re-factoring everything to make the code more beautiful, you’ll never get anywhere.