I read this quote somewhere recently, though I cannot find it on the internet anymore. But I love this:

The gap between theory and practice is not as wide in theory as it is in practice [anon].

I have spent a lot of my free time in the past 26 years writing/speaking about the subject of database design from a standpoint that most of the theories that academics come up with are more misunderstood more than they aren’t generally practical. If you read about normalization for example, it more often than not put into terms that sound like a math class taught by a math professor who believes that calculators are evil. And the only people who really love reading math books like that are academics (or people who 100% should look into an academic path!)

But every one of the normal forms is there to help guide a person designing a database down a path where they create the best database they can; for the requirements they have.

All they have to do is take a bit of time and think through the data structures they are creating. But in that last sentence is one of the largest barriers of them all. Time.

The battle of now and later

I am not talking about the candy of course (but I think about it every time that phrase is used), instead I refer to the concept of time. I hate the phrase “better is the enemy of good enough,” even if I pretty much agree with it in, well, theory. The problem is that it can become an excuse to put out garbage fast, then apply the the concept of failing fast in a way that it shouldn’t be used. Try a new fragrance to see if it is ok and everyone hates it, cancel it. Try a new material for skydiving, failing fast means falling fast. Ouch.

That phrase is about taking something that is perfectly acceptable and embellishing it is generally unnecessary. (Also known as gilding the lily.) And like any computer programmer, I have been frequently guilty of that myself.

The problem with all of this is that the goal isn’t to put out a mediocre implementation, but rather to only do as much as you can in the time that you have. Give the customer a solid piece of software that does one task and see if the functionality does what the customer needs. This being the most common version of testing in production that no one argues about (though they don’t typically call it that like I do!)

It doesn’t mean ignoring best practices

Best practices are generally just theory put into practice. There are very practical reasons why we build OLTP databases using the tenets of relational theory and normalization. There are practical reasons why we take so much time figuring out the best names for objects in a database. There are practical reasons for pretty much every database (and coding) practice that are rooted in theory. (And it isn’t guilding the lily when you work on your UI to make sure all of the [OK] [Cancel] buttons are in the same order so accidents aren’t made.)

For good reason, the theorists didn’t think about the ticking clock making noise as we are trying to meet a deadline. They thought about what the way to get the best output from the crazy practices and business rules that would be tested in the process.

The bottom line

Short projects, long projects, finished projects, minimum viable projects (I hate that someone decided to find an acronym that also doubles for “most valuable player”), or anything in between should not ignore getting a product that will be fundamentally sound and able to be use for years.

Because no matter what someone calls “minimum viable,” there is very likely no going back and fixing the internal stuff that will cost you for years to come. In fact, more likely more and more stuff will need to be bolted on that exacerbates the issue, whether you think the theory is practical or not.