Shipping software is hard. Even if you are just packaging it up lightly so you can put it on a couple machines in Accounting down the hall, once it leaves your protected little world, anything can happen. And usually does.

And so we have TDD and BDD. Code reviews. Pair programming. Code coverage reports. Programmer testing. QC testing. QA testing. Performance testing. You get the idea – we have a lot of ideas about how best to make the transition of our software out to the real world as smooth as possible by making sure the software is good enough.

Good enough. That’s the key words here. Unless you have written a very trivial application, you will never ship something bug free. Think about that for a second. It’s depressing if you let it get to you. Now, think about some of the things that count as bugs – some of them are issues because the software doesn’t work the way the user expected. Or other things you couldn’t have possibly envisioned anybody doing with your software. It happens.

If you try to fix all of the possible issues, you will never ship. This leads me to a theory I’ve been toying with, the one that has to do with shipping software: Never trust a consultant who hasn’t shipped software in X years.

I haven’t decided yet exactly how many years. Maybe you just have to go with your gut. But the more I read from industry luminaries who espouse things like all code must be covered by tests that were developed in a TDD fashion or that you have to develop on the trunk so you can continuously deploy, the more I think that my theory might just be worth  something. ¹

I’m not saying to forget about this advice. Its good advice, in theory. But don’t take it to an extreme. Extremes tend to cause pain.

¹ In fairness, I’ve been a change agent at various points in my career. I know that sometimes you have to make an extreme statement (and follow through with it) in order to break old habits and effect change. Ask me about stored procedures sometime…