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

Question

I have sales people and bean counters who are trying to sell customizations to clients, which is fine. But when a complex change request comes in that I send back a large estimate for, they get confused. Often they come back at me with "Why can't you just add another column?" which by another, they mean a dozen or so custom columns PER client.

So far all I can come back with is "We are trying to keep the database well normalized" which means nothing to them. I tell them I can create a system of tables that allows each client to define their own set of custom fields, but of course that takes more time and money than "just adding a few columns". And of course they want to have their cake and eat it too.

So how can I make them understand?

Answer 1

I tell them I can create a system of tables that allows each client to define their own set of custom fields, but of course that takes more time and money than "just adding a few columns".

I think you should push this option to your bosses since customizability is obviously a feature much in demand. Emphasize that an individually customized (rather than generalized, limited customizability) system for each client means that patches and updates will have to be created for each individual client (leading to longer roll-out times and higher costs); that non-standardized installations mean that HelpDesk tickets will take much longer to close (leading to dissatisfied clients and higher costs); etc.

In other words sell short term pain for long term gain by showing that the cost of their solution far outweighs the cost of your solution.

Salespeople are focussed on making the sale. That's what gets them their commission. They don't care about what comes after. Bosses, however, are focussed on cost. Sell to your bosses and your bosses can sell to the salespeople.

Answer 2

The best way I've found is to show how you can create a new feature out of what they're asking for that you couldn't add with just a couple customized columns. Features are better than customizations, especially when you can charge someone for it.

Try to make a good business case for your side before you get into the technical stuff.

Answer 3

Ah.. a little knowledge is a dangerous thing.

Try this one:

You: Which companies did we fail to sell to?
Sales: Acme Industries, OCP Corp, blah blah blah
You: Well.... why can't you just make a couple of more phonecalls?

The answer of course is sales isn't that simple. Neither is software development. Unless they really want hours of explanation in regards to architecture and maintenance I suggest they trust your judgement as a software developer.

This is the issue here, trust. You should explain to them they are displaying a lack of trust in your abilities by making these statements.

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

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.