As a data architect, and writer on the same subject, I am completely entrenched in learning and applying the discipline of normalization. When I set my course down the road of great database design, my motto is “Fifth Normal Form or bust“, even if it takes months to finish the design for just a few tables (and, of course, to make sure every table and column is meticulously named). Not much gives me greater pleasure than the beauty of a database that has been honed to a high degree of normalized perfection and that, to the amazement of the many detractors and doubters, also performs magnificently.

If this sounds like one of Lewis Carroll’s stories, there is good reason for it. The reality is that I don’t live in Wonderland, and rarely get time to design anything, much less everything, in meticulous detail. My average project tends to fall into one of two categories

• The Surprise Project – about 30 seconds after you fall asleep for the night, a mobile device starts dancing to that catchy ringtone that was annoying 10 years ago. Something has failed and it is time to fix it. As long as the problem wasn’t caused by you, this can be the most rewarding times of your career, as you put on your Superman Underoos and save the day.
• The Incredibly Urgent Project – after months of furtive meetings between various marketing and project managers, over the need for some innovative new campaign, advertising scheme, or product line, a decision has finally been made to go ahead. And they need the project to start…immediately! And the delivery date is…as soon as possible!

My normal workday, as a result, most closely resembles a typical episode of the TV show, Junkyard Wars…”Contestants, you have just 10 hours to build a fully-working dragster from the contents of this junkyard.” My favorite team welded together an old motorcycle and a rusty golf cart and went flying down the track. Their solution would never work long enough to survive the complete drag racing season, but it survived 2 trips down the eighth mile. They knew for how long their solution would be used, but most software built like this, with a planned expiration date, usually last years longer than expected.

Many project are like this; get it done quick. The best theoretical solutions need not be posited; your deep and hard-won knowledge of advanced “internals” is of little good to you here. Practical is what is required. When a manager says “as soon as possible”, they don’t mean “as soon as you can reasonably arrive at the optimum database design and then build a proper solution with stringent application of sound programming principles“. They mean “why haven’t you got something to show me, already?“

The oft-heard battle cry from management is that “Better is the enemy of good enough”; true, but in the wrong hands, very dangerous. Too often, the definition of “good enough” is taken to mean something works to the point that the manager can check a box, no matter the implications to the future user or maintenance workers.

Does this mean that all of your training, all of your dedication to doing your job the right way, is useless? Not at all; in fact, it is going to be more necessary than ever. Just because your solutions need to be devised with practicality and timeliness as a priority, it doesn’t mean that you can actually do things poorly or technical debt will pile up like dirty clothes in a dorm room. It does mean, however, that you need to stop aiming for perfection and start shooting for “good enough”, but where good enough implies a practical solution that adopts at least the basic software engineering principles, and a solution that you are comfortable releasing to the users, even in the knowledge that an even better solution was just out of reach.

Almost every solution that is created according to a definition of practical that means “delivered tomorrow” is doomed to be a lesson for the next project; when practical means “as good as practically possible”, everything will usually be alright.