“We’ll fix it in the mix.”

“It’s good enough for right now.”

“We’ll worry about that later.”

“Your check is in the mail.”

Of all the traits that make Homo Sapiens unique in the animal world, our capacity for self-deception may be the most amazing. I know of no other species that goes to such great lengths to convince itself that what is, isn’t, and what isn’t, is.

We make poor design decisions because “it’s important to get something out there”, swearing on the microprocessors of our ancestors that we’ll fix it “first chance we get” – a chance that, unsurprisingly, never comes. We deploy mediocre code because “we have to get it done”, and make solemn oaths to our children’s children that we’ll optimize it “as soon as we have an available resource” – said resource having meanwhile been assigned to another helter-skelter project that will result in more poor design decisions and more sub-optimal code because there’s all this “stuff in the pipeline” that just can’t wait.

Then – and this is the kicker – we wax poetic in blogs and publications about “the 80-20 rule”, and how “there’s never enough time to do it right, but always enough time to do it twice.” We commiserate over beverages hot and cold about tight deadlines and too many features and reports that no one is going to read anyway.

And then go right back to writing queries with twenty-six joins and wondering why the hell it runs like a three-wheeled motorcycle trying to pull a house trailer, because “we need to get it out there”, and promise ourselves that we’ll fix it tomorrow.

As we all know, tomorrow never comes.

It’s not easy to say “No” when someone asks if that stored procedure will be finished in a couple of days. It’s hard to insist on taking the time to do things right when the people higher up the food chain think they have eleventy-seven perfectly good reasons for doing it in a hurry. It’s tough being the only wizard on the bridge when the Balrog shows up.

But, somebody’s got to do it. Not doing it means repeating the mistakes of the past, over and over again, going around in circles while knowing full well that the Promised Land is just over that hill – if only you could get there.

I try to frame these issues to management in terms of dollars and cents, because everyone understands the principle of the bottom line. I try to explain that poor design means poor performance, poor performance means extra CPU cycles, extra CPU cycles mean more electricity, more electricity means less profit. I point out that slow queries mean idle hands, and idle hands mean someone’s getting paid to wait, and waiting isn’t adding to the revenue stream. I talk about servers and edition upgrades in terms of investment, not expense. It doesn’t always work: some people make up their minds about something and neither love nor logic will stir them from it. But it’s important to try: it’s important to take a stand.

After all, the CEO helps those who help themselves – or so we hope.