I am working on a survey app for a CEO (who has a degree Computer Engineering). For the part where re record the results, he is insisting that I simply add more columns to database every time someone ads more questions.

Document the code in such a way as to indicate that the weird database design was due to the specific requirements of the site owner - but do it in a way that simply explains why the code works the way it does. You'll need that as a reminder for yourself if you work on it again in a few years time so as to remind you that the owner had a requirement for it to work that way.

Fair enough, and I reckon what felgall suggested is a nice neutral way to do this while saving face at the same time.

felgall said:

Document the code in such a way as to indicate that the weird database design was due to the specific requirements of the site owner - but do it in a way that simply explains why the code works the way it does. You'll need that as a reminder for yourself if you work on it again in a few years time so as to remind you that the owner had a requirement for it to work that way.

I am working on a survey app for a CEO (who has a degree Computer Engineering). For the part where re record the results, he is insisting that I simply add more columns to database every time someone ads more questions.

I couldn't even respond with words as I cringed and wanted to throw up mere suggestion.This goes against every principle of RDBMS design I have been taught.

How do I tell him he is wrong without coming across as a jerk?:x

I've been in this position a few times, and I've done a few things.

First, if it is an existing product, I'll work up time estimates for me to alter the existing system (the way it is designed today) and I'll work up estimates that utilize a new design that fits better with best practices.

Usually the new design is more costly up front, so to help sell it, I look to advantages of the new design, faster, better performance, better scalability, easier to maintain, etc. Some of these are intangible items, others can have true dollar values associated to them. You have to remember that your boss, CEO, etc only care about the numbers (usually). So if you can show it is better for the business and not just because you don't like how it is setup, you are more likely to succeed.

If it is a new product, and the client is trying to identify how the design of a database should be, I back out of the project. Of course this isn't a luxury everyone has, but you will see me do it time and time again. Why? Because that is a HUGE red flag that the client will be more of a hassle than what it is worth and regardless of how well I do and if I implement their design versus a better one, he will focus purely on the negative aspects at the end.

If the client is merely suggesting an idea from a prior estimate, that is slightly different, so long as they are open to ideas on improvement of their design or open to using a design of my own, things usually work out okay, but still isn't a best case scenario.

Don't be afraid to present your ideas of improvement. A good boss will recognize this as a good thing, but realize that sometimes it doesn't make sense for a company to invest in a redesign, but rather keep the current product moving forward in the state it is in (comes down to the numbers), but never stop giving your ideas to your boss if it 1) leads to improvement, 2) leads to easier maintenance, 3) scales better, 4) can reduce business cost in the future, etc.