Perfect is the Enemy of Good

There aren't many win-win situations out there. When you find them, it makes your whole week. Most of the time we are working on projects that have complex ramifications. There are goods and bads for every decision you make. The question becomes... which bads can you live with?

It used to be that software and systems development was a creative practice, then came this panacea of "best practices" as though there is only one way to do things, and we all must march in lock-step to the same tune, same dance. Though this is bad enough in the real world, now we have development systems (such as Visual Studio) that will actually "tell you" what you are doing "wrong", and how you should be writing your code. And this is automated!!!

Imagine that, the human used to tell the computer what to do, and now the computer tells the human "the right way" to do things. Anyone who does not see the horrible paradox in that fact, and where it dictates we are headed, has to be a blind person.

In the real world, timelines press, and clients want results and this boils down to a very simple factor: If the software works, and works largely efficiently, does it really matter whether or not "best practices" are applied?

For those of you who would answer "yes" to that, I say enjoy your life in fantasy land. In my decades in this business, the reality is that business thrives on revenue and I have never once heard a client say something like: "Oh please, yeah, take all the time you need to deliver us perfection!". It just doesn't work that way.

I am all for "best practices" as a discussion and education tool - but when you are in the heat of battle with timelines crunching down on you and a press for meeting revenue numbers, you cannot stop time and live in some fantasy land. You deliver, or you go out of business.

THAT is the most simple "best practice" to understand in the real world.

I've inherited the role of DBA from time to time, although never officially. I've always tried to balance the "best practice" approach versus what makes sense at the time.

I think that the key is to know where your shortcut is weak, and to document that along with it for the next person who comes along to support it to see. It's true that you may not have all the time necessary to build the perfect setup, but if you know where you are weak, then you can communicate that to management and the team so that if that weakness becomes a problem, you can address it.

I've found that far more dangerous is the zealot who does not understand what the purpose of the best practice is, and then wields it like a baton, causing more problems as overly complicated solutions are put into place in the name of best practices, when a simpler more elegant solution would have sufficed.

A number of years ago I was mentored by a management consultant whose favorite line was "If it doesn't matter, it doesn't matter."

It took years for that to sink in, but once it did I realized that I was wasting a lot of my time trying to come up with a "perfect" solution when I should have been focusing on coming up with a good solution.

In short, I was always letting "perfect" be the enemy of "good" as I was always trying to solve for any potential future problems.

My criteria now is: Does it meet our current needs, is it flexibile enough to change as future needs evolve, and can get it be done in a reasonable amount of time?

If so perhaps it really is the perfect solution.

I look to seasoned practitioners in the field and they seem to have developed attitudes that are flexible and nuanced. They can say "it depends." They can identify and navigate tradeoffs. Through trial and error, and forrays into business ventures where they're putting up their own time and money, they've gained new perspectives on managing technical projects other than the role of technician.

Alistair Cockburn is one example. He uses the term "adequate" a lot - and this is thought-provoking to me. There are times when a technique labeled "best practice" isn't the best choice for the time/money investment needed to implement it. A practice that's "adequate" can frequently keep the project in the safety zone while meeting more important objectives better.

It's possible that some technicians who review this discussion might soften up on the "this way no matter what" stance and learn to take a more nuanced stance. I'll let some of the other posters hammer away at that and lay out the logic.

I want to bring up a concept that I think complicates the topic a bit - you know - for some of those who've circled this discussion plenty of times before.

I think business decision-makers are constantly tempted with the prospect of getting something for nothing. There are certain costs that they want to avoid and pretend do not exist. They're too focused on getting certain rewards that are either real or imaginary.

Certain patterns of the "something for nothing" temptation are apparent to us technicians. We see businesses we work in or around us "sweating their assets" in the form of letting servers get old and unstable - to the point where the risks are bad and they're way out of the safety zone and the entire enterprise is in jeopardy.

We watch decision-makers put together a data-driven enterprise and then side-step the cost of a DBA - and let far less experienced staff hack away at any problems that come up and let them build solutions with inadequate training and experience.

I think partially what feeds the inflexible attitude that some techicians take is experiences like what I've mentioned above. There's a lack of trust. Some technicians don't believe that the decision makers want to acknowledge the tradeoffs. They feel it's their role to not just advocate but insist on certain investments.

This is understandable - but ultimately it's better to become more nuanced.

It's an ocean out there - with lots of waves and currents going on at the same time. There are savvy business people and there are greedy, ignorant business people. There are seasoned technicians with business acumen and there are technicians with little or no business acumen. There are varying degrees of training on cost-benefit analysis and trade-offs. There are a variety of projects where a spectrum of techniques with varying levels of stringency can be applied with varying results. There are successful voyages, shipwrecks and failures to launch.

Meanwhile, hopefully we're all learning.

Having been a database professional for almost 16 years now, it seems the vast majority of that time has been spent dealing with or fixing those corners that other people have cut. It's funny to me that people are so easily willing to give up many more hours in the future to save a little bit of time now. It's awlays a loose-loose scenario.

I will say I believe there is a difference between cutting corners vs. best practices though. For example, many people rely solely on normalization to design their databases, but I'm from the school of thought that normalization is only analysis, not design. Even in a pure OLTP system, if there were such a thing, it would be impractical to always follow all of the normalization rules. The approach I use is to normalize in initial analysis then denormalize some things for practicallity and performance reasons.

With almost 20 years in IT myself, I agree. When it comes right down to it -- the customer, whether internal or external, has to be willing to pay for what you are doing. We do the best we can to insure standards, but when it gets right down to it, value-to-cost is the #1 driver for everything.

Find a new job. QUICKLY. 🙂

Seems pretty straight forward to me:

if effort_required_to_do_it_right < effort_required_to_hack_it_together + SUM(effort_required_to_fix_it * probability_fix_is_required) then

do_it_right

else

hack_it_together

end if

🙂

Who decides what is right (or better, when it is right), the developer or the client/stakeholder/user?