I read an excellent article by Camille Fournier about the importance of recognizing that being right is not the only factor that needs to be taken into consideration when making a decision. You could even change it from “being” right to “doing” right. Although, I mean it in a technical sense, not a moral one.

If you haven’t read it already, go ahead, I’ll wait…

I agree with her.

I’ve been that guy… more than once…. okay, okay, a bunch of times. You know that guy. The one who just couldn’t see past the point that we were doing something wrong, something stupid, something that would bite us in the butt for the next three or four years. Oh yeah, that guy. The popular one (not at all). The one the that causes the to boss starts to cringe whenever that guy heads towards the office. Been there, done that, have the embossed external hard drive.

Now… over the last several years, I’ve made an honest and sincere effort to not be that guy. I’ve tried pointing out the flaws, making my arguments, and then, if they get shot down, lose quietly & gracefully. Sometimes I’ve been successful. Other times not so much (times 100). I usually gaged how successful I was by how angry one member of my team, who never compromised, became.

The only thing is, well, sometimes, that guy (or gal), is 100% correct.

Not only that, but the boss/program team/consultant/whoever on the other side of, what to mean seems a silly argument, ready to toss common sense out the window in order to deliver software faster (because it always seems to come down to how fast we deliver the software) is 100% wrong. Not only are they wrong, but they’re destructively wrong. Project wrecking wrong. I’ve seen it happen, multiple times. That’s why those of us who do tend to act like that over-wrought freak-out queen put on our performance. I know we’re crazy to thins it’s a really bad idea to throw out relational integrity, stop designing databases for optimal storage, rely on the app for all integrity checks, use an ORM tool as an OOM tool, skip testing for deployments, stop maintenance routines and monitoring, or just flat out ignore the laws of physics. We’ve seen the projects fail because we understand how things work. We just can’t always explain that understanding to others.

So the real key here is that you have to split this hair mighty fine. Yeah, giving up on some processes, some best practices, in some situations, that really can make all the difference in getting software out the door faster & more efficiently. No question. But, those same compromises can lead to absolute failure. Management has to be able to listen to weed out the best practice complaints from the technically unsound complaints. And we geeks have got to stop having the vapors every time a developer proposes making a change to the system or a process. Otherwise, we won’t be listened to when it really counts, like the Boy Who Cried “Wolf!”