Click here to monitor SSC

What Counts For a DBA: Practicality

Published 15 December 2011 9:56 am

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.

9 Responses to “What Counts For a DBA: Practicality”

  1. ALZDBA says:

    This lesson took me more than a year to realize and accept after I switched from a banking company to a … let’s say … company which positions IT just as a needed evil to support production.

    You have worded it really well !

  2. colinbul says:

    Project Managers/Technical Architects/Developers/Hell most people in IT; plan for the long term life of a product/solution, when really it is just tactical solution and ‘good enough’ is the optimum often solution (In terms of money and business value). I whole heartedly agree with the ‘good enough’ theorem and when it is done by the correct team ‘good enough’ is often the perfect solution from a business value point of view. However, in my experience ‘good enough’ is often delivered by people who ‘do not know enough’ thus you end up with a unmaintainable, sub optimal solution, that you end up investing far too much in the initial release cycle and subsequent changes/maintenance, thus the expenditure/business value drops significantly.

    I see this most in projects that are ‘off-shored’. Fine the day rate is much lower than consultants excluding the upfront cost of delivering workpacks and defining SLA’s etc, etc. But it is often 3-4 inexperienced people with little or no domain knowledge that end up implementing the solution and a few in house people are left to pick up the pieces during release and testing.

    So in short: Managers/Board Member et al, make the practicality decision upfront with out full consideration of the conseqences and all ‘true’ experienced developers/administrators can do is pick up the pieces in the way you describe.

    I think this is often a situation that can be avoided.

  3. kramaswamy says:

    Completely agreed. One of the biggest lessons I had to learn after finishing my degree in Computer Engineering and transitioning to the real world, is that most of the stuff I learnt in school just didn’t apply anymore.

    Planning out projects for months in advance, applying proper requirements analysis and test-driven development principles, etc, all work well in classes, but in reality, it’s very difficult to get any of this to work.

    I think what separates a great developer from an average one, is the ability to realise your constraints, both in terms of time and manpower, and create the most flexible and adaptible solution you can come up with. Sticking to principles will almost always cause your projects to go off course in terms of time and/or money, but at the same time completely ignoring your principles just for the sake of speed will simply result in your projects being impossible to maintain in the future.

  4. drsql says:

    Love the comments, and I agree completely. I am not insane enough to believe we could have unlimited time, but I also demand (not get necessarily) that get enough time. One major project I was involved with for the company I currently work for (14 years total) was majorly messed up because of a poor mix of good enough, high dreams and skill level. Only 2 developers remain from those days, and we (and the rest of the team), still pay for this 3 years later. Good enough wasn’t good enough.

  5. ALZDBA says:

    “You Can’t Always Get What You Want” by The Rolling Stones ( 1969 / Let It Bleed )
    contains an applicable chorus:
    “You can’t always get what you want
    But if you try sometimes you just might find
    You’ll get what you need ”

  6. DeafProgrammer says:

    Well written article. I used to worked with these Project Managers/Technical Architects/Developers for years. They have abosolutely no idea of how’s the database works. These people are building a house without a foundation.

  7. Anonymous says:

    Of all the valuable attributes of a DBA covered so far in this series, ranging from passion to humility…

  8. [...] eschew common sense to push their underlings to exhaustion, we DBA/programmers, even the most practical ones, are equally to blame for having unrealistic expectations of what we can achieve in a given [...]

Leave a Reply

Blog archive