You have probably heard the phrase “The perfect is the enemy of the good” before, and usually when someone is recommending a less than best practice type approach to a problem. Given time and money, I’d always opt for the best solution – the one that handles all the edge cases, performs well, and is highly maintainable. But what if you don’t have enough time or money to do ‘best’? How does a business decide where to trim resource usage?
At the risk of getting blasted for a less than stellar example, I’ll share one of my own. For the past couple years I’ve been slowly building the SQLSaturday web site. Because it’s a no profit venture, I have to make the most of the time I can devote to the project, and that means that I’m open to cutting a corner or two. In a well-designed database I’d have a speaker table and link each abstract they submit to their speakerid, allowing me to keep all speaker-centric details in one place. Instead, each time they submit an abstract I capture all of their details, duplicating data, and opening up the chance that a single speaker will have multiple email addresses or worse across events and abstracts.
It saved me a little time, and time mattered. But I also know that even with some not quite pristine data, I can go back when I have another chunk of time and fix this with minimal impact on the overall application. That’s IF it ever makes sense to make the change.
Don’t get too caught up in my example. Just remember that we almost always have constraints, and one of the great values we can deliver to the enterprise is helping them understand which corners can be cut, and which ones can’t.
