Explaining why “Just add another column to the DB” is a bad idea, to non programmers [closed]

Answer 1

If they're sales people and bean counters, then they will definitely understand the almighty dollar (pound, euro, etc.). Can you demonstrate that the time spent to maintain these extra columns doesn't justify the added sales?

Be very careful here and make sure your argument makes sense. I've found myself resistant in the past to doing customizations more because I didn't want to ugly up my pretty little domain model than because it would really be that difficult to maintain. A decent analysis will help you determine why you're resisting the customization.

Remember - the bottom line is that you need to keep clients happy in order to stay in business. We thoughtful developers can sometimes lose sight of that in our quest to make things maintainable and simple.

Answer 2

I've never tried this myself, but I've thought about it: draw an analogy to the legal system. Legal loopholes exist because law makers try to patch the system with lazy kludges. The software equivalent is bugs, security holes, etc. The only way around these problems is careful planning and hard work.

Answer 3

You won't get anywhere explaining it to them in technical terms. You need a metaphor. Tailor it to the person you're talking to, if you can. If he/she is a car freak, get them to think in terms of engine modifications. How much would it cost Ford to offer three different motors in the Taurus, or custom mods on demand?

Once they accept that comparison, even if they don't fully understand it, you can begin to get into why the metaphor applies.

There's another great way to help them see it your way- take some time to see it their way as well. When your paycheck depends on giving the customer what they want, you don't care what the propellerhead in Engineering tells you. If you're getting a lot of requests for customization, you should consider the architectural and strategic approaches to delivering those customizations, wherever possible.

Answer 4

You can tell them that a poorly designed database means that in the long term:

• it will take longer for them to retrieve their data - do they really want to wait and wait?

• it will be harder and take longer to design queries to generate reports - again, if they need that query tomorrow, do they want to be told that it's still being worked on?

• it will be a nightmare to maintain, with error prone queries more likely to be written.

Answer 5

Tell them that when people make a car and then they want a model that goes faster and does more than the previous, they usually don't add another engine.

Answer 6

The problem is that "We are trying to keep the database well normalized" is almost certainly the wrong answer - it plays back the ball into the court of mistrust and cross-purposes.

You have got to turn focus back onto the end goal, how best to meet that end goal (perhaps in several releases) and what it will cost in the short and long term. I've seen mention of technical debt in answers and cost estimates should take those factors into consideration.

It might not be a bad idea to "just add another column?". You really haven't given the entire business case. On the other hand, they have challenged your negative response with an ignorant technical question. That doesn't get to the heart of helping you understand the requirement because they didn't like hearing "no". (I'd like to know what the original statement of the problem was.)

Making the database normalized is a technical problem and has no bearing on the requirements the system must satisfy - it is a system design principle which you use to deliver systems with certain properties like maintainability. But a maintainable systems which don't meet user needs have zero value, while unmaintainable systems which do meet user needs have non-zero value (which might be exceeded by the cost of maintenance - which is a business problem). Whether EAV or some other mechanism is required is not really the point either - that just causes system complexity or cost to increase.

If the requirements are too expensive to ever implement, then that's part of the business case. You haven't told us enough about the architecture or the type of entities these tables model. Say you have 100 clients. There may be overlap in columns in a particular entity. Just as many as 95% of clients will never use the optional Billing-Address or a Middle-Name column, that doesn't mean those columns are left out - not only that, they are often in an original design! Alternatively, if this is a Products table and every client wants many special columns and there is no overlap, you might need a user-defined field system (EAV/XML/tag - the design will have to match the requirements) instead in order to maintain a cohesive system design.

I have rarely found business to ignore a technical debt argument - particularly if a proposed solution can be shown to meet the user needs and flexibility can become a selling point. What I have found is that business will often prefer if you present solution choices as quickly and thoroughly as possible without spending more time explaining why something can't be done or how much it's going to cost than it would take to buckle down in a couple afternoons and actually getting the work done.