How To Deal With Terrible Design Decisions

Question

I'm a consultant at one company. There is another consultant who is a year older than me and has been here 3 months longer than I have, and a full time developer.

The full-time developer is great. My concern is that I see the consultant making absolutely terrible design decisions. For example, M:M relationships are being stored in the database as a comma-delimited string rather than using a conjunction table to hold the relationships.

For example, consider two tables, Car and Property:

Car records:

• Camry
• Volvo
• Mercedes

Property records:

• Spare Tire
• Satellite Radio
• Ipod Support
• Standard

Rather than making a table CarProperties to represent this, he has made a "Property" attribute on the Car table whose data looks like "1,3,7,13,19,25,"

I hate how this decision and others are affecting the quality of my code. We have butted heads over this design three times in the past two months since I've been here. He asked me why my suggestion was better, and I responded that our database would be eliminating redundant data by converting to a higher normal form. I explained that this design flaw in particular is discussed and discouraged in entry level college programs, and he responded with a shot at me saying that these comma-separated-value database properties are taught when you do your masters (which neither of us have). Needless to say, he became very upset and demanded I apologize for criticizing his work, which I did in the interest of not wanting to be the consultant to create office drama.

Our project manager is focused on delivering a product ASAP and is a very strong personality - Suggesting to him at this point that we spend some time to do this right will set him off.

There is a strong likelihood that both of our contracts will be extended to work on a second project coming up. How will I be able to exert dominant influence over the design of the system and the data model to ensure that such terrible mistakes are not repeated in the next project?

A glimpse at the dynamics:
I can be a strong personality if I don't measure myself. The other consultant is not a strong personality, is a poor communicator, is quite stubborn and thinks he is better than everyone else. The project manager is an extremely strong personality who is focused on releasing tomorrow's product yesterday. The full-time developer is very laid back and easy going, a very effective communicator, but is someone who will accept bad design if it means not rocking the boat.

Code reviews or anything else that takes "time" will be out of the question - there is no way our PM will be sold on such a thing by anybody.

Answer 1

From my experiences

I would say as having been a long time contractor myself, 20+ years, generally when you are a contractor, you aren't there to affect change, you are there to be a warm body filling a seat and doing what you are told, unless your manager mandates something different specifically.

Don't get invested

If they don't see the huge mistake this is, then don't worry about it. Make some comments in your code contributions about how this is bad and needs to be refactored to actually support joining against those values in a sane amount of time, and then forget about it. It might even end up on thedailywtf.com and make you anonymously famous!

Start thinking about how you are going to make sure your next contract position will be so much better than your current one! You now have an experience to help you gauge the next set of people you will be working with next time you interview, to detect these type of personalities in the future.

You not only want to be aware of the contractors negative personality, but also your managers negative personality. If he is going to "blow up" at someone who is trying to make him look better and avoid problems, you need to learn how to spot people like him in the future so you can avoid them as well.

You should not have apologized

Now the other contractor will feel justified in his belief he is correct, which he isn't correct.

Any basic Relational Database Theory book will shoot down this naive incorrect solution in the second chapter, if not sooner. Multi-value fields are a clear sign that someone doesn't comprehend what they are doing, they aren't worth your time arguing with.

If you really want to do something to make yourself feel better

Document your conversation with this person, why it is so wrong, what problems it will cause and your proposed solution. Give this to the salaried employee and your manager. Don't propose that you change it right now if you have a deadline, but make it really clear that is isn't going to scale and will definitely make your manager look bad in the near future. That way when you have moved on, you can feel good in the fact that you at least notified them of the disaster waiting to happen.

Answer 2

Your best bet is to develop an ally in the full-time developer. Talk to him about the design flaws and see if he agrees. If you can get him to see the problems inherent in the current project, you may be able to convince him to go with your methods on the next project.

Thats one way to influence the situation without causing heavy collateral damage.

hope this helps!

Answer 3

First off, you probably shouldn't have apologised - it just makes him feel "righter". Criticism is an essential part of any project (at all, not just coding). Second, you could knock up a quick test case to demonstrate just how much faster the proper way of joining tables is, and ask him how, using his comma lists, you could go about picking out all the cars that came with iPod support?

Answer 4

When I was a consultant my rule was, when I disagreed with a technical decision I would tell them why(with supporting arguments) exactly ONCE. If they didn't want to take my suggestion, no big deal, I won't be maintaining it.

Answer 5

This is a pet peeve of mine..... Putting aside the correctness of the decision, a decision has been made that you don't like- each of us will deal with 100's of these in our careers. You appear to be refusing to accept it and going behind peoples backs, playing silly games to get it changed. This behavior will undermine the working relations not only between yourself and the other party, but , as you force people to take sides in an unwinable war, all other relationships in the office. Your behavior is immature and destructive. Your job, (what you are paid to do), is to ensure the success of the project. Destroying the team relationships will do this 1000 times faster than one bad design decision.

So how does a mature consultant deal with this. They present an argument as to why the chosen design is inferior, and suggest the better alternate. After a rational discussion, a final decision is taken and committed to by everyone. A professional consultant will, by the very way they work, have documented evidence on all of this, just in case.....

So what are your choices : a) Grow up and be professional about it, b)get fired or c)resign. If you can't do a), please do c) before you destroy the project.

Answer 6

First you are correct this is a very poor design. Do not ever apologize for professionally disagreeing, apologize only for poor behavior on your part (yelling calling names, etc.) not professional disagreements. He owes you an apology for his behavior of being unwilling to accept a professional difference of opinion.

Now if someone told me this, he is how I would have presented my argument back to him if he wasn't convinced originally. Run up a quick test table with 10,000,000 records with an id in one column and a comma delimited numbered list in another and a second lookup table that the numbers relate to with an id and a description. Then create the proper normalized structure. Now do the same thing in a correct relational design. Don't forget to create appropriate indexes. Now write the code to find all the ids in table 1 that have a value of test3 (which would equate to 3 in the delimited list, but you need to do the join to the lookup table to know that) with the badly designed structure . You write the code using the normalized structure. Compare the code, the time it took to write the code and the time it takes to run the code. You and I both know which will be shorter and take less time to write and perform better. Show the results to the PM and prove to him that the bad design is causing the project to be slower to develop and will perform worse when it is deployed. If that won't convince him, then nothing will and you need to find a better contract ASAP because this project has a 0% chance of succeeding.

Answer 7

A thought - in case this situation deteriorates, keep a file somewhere listing the things you think he is doing wrong. You'll probably never need to use it, but it might become important if this escalates.

Make sure he can't find it!

Answer 8

It looks like you are stuck between a rock and a hard place. You are obviously trying to do the right thing but your co workers don't agree with you. Your two options from what you said is note fully how you tried to make it right and keep your mouth shut or look for a new job. People in high places make bad decisions that have to be dealt with sometimes.

Answer 9

If the design is very bad and you are both consultants, you need to bring it to the customers attention and state your concerns that this might end up being software that is expensive to maintain.

It is then up to the customer to decide where they want to put their money. If they go with the bad design, well, at least you told them, and then it is your duty as a professional to do the best job you can within the circumstances.

Answer 10

His solution is obviously a bad design choice. It's obvious even for me, who almost never worked with a database. I can immediatly see the restrictions imposed by this solution, and I can't see any added value.

I don't understand why you can't just convince him with simple evidences. As I said, I am not into databases, but I recently had a similar situation than yours, with a coworker who had to design a database. I was able to tell him the pros and cons of both solutions, and convince him that in our situation, one solution was better.

It's really a communication problem, here. Either you argued with him in such a way that he felt attacked, or he is very stubborn and is not able to receive criticisms.

Answer 11

TBH his design isn't great but really isn't so bad. Normalising everything can lead to a plethora of tables that become hard to keep track of. Serialising attributes into a string makes it easier for objects to save and load. You see similar type of thing where objects are serialised to xml and stored in a blob column.

The real problem is how you deal with differences, you need to get over it. You dont like how he has done something, bad luck. Sounds like you're the most junior guy on the team. In 10 years when you're the boss you can push through your solution through even when others dont like it.

Until then, you have the least power and influence. Spend your time worrying about something more important, like how to get a raise or a job somewhere else.

Answer 12

You must both have someone that you directly report to. Time to escalate it to him and see how he/she wants to proceed. If you're not working for a company that's willing to take developer talent concerns seriously, go elsewhere.