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.

  • 1
    Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information.
    – user8
    May 16, 2011 at 0:00
  • 3
    You were argumenting with "theory" (like "that is how it taught", and words like "normal form" and "redundand". He obviously does not get that. Try something more real .. ask him to write a join for that one
    – Flo
    Jun 6, 2014 at 9:53
  • This is a rant. VTC.
    – david.pfx
    Jun 6, 2014 at 14:18
  • @Flo Exactly. This is a really easy argument to "settle" by asking him to do a join against his design.
    – Evicatos
    Jun 6, 2014 at 17:52
  • "our database would be eliminating redundant data by converting to a higher normal form." - okay so why is this better? (Likely answer: because you can do joins. But then you have to explain why doing a join is better than using split() and loop in your code)
    – user253751
    Nov 1, 2017 at 1:23

12 Answers 12


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.

  • 6
    Agreed. If they don't understand why that's a bad decision, they are clueless idiots. Do your best and let them crash and burn in the future. May 12, 2011 at 16:16
  • I wouldn't say "clueless idiots" but I would say their priorities and concerns are not inline with the posters concerns. Which might be ok given the project circumstances that we don't know. Either way they should learn how to spot these personalities and types of projects so that they can avoid them in the future.
    – user7519
    May 12, 2011 at 17:55
  • 7
    Well yes, perhaps "clueless idiot" is a bit harsh. But there are some things in software development that I would think should always be in place or it shows a real lack of knowledge on the part of the team and, maybe, the entire company. May 12, 2011 at 18:08
  • Thanks Jarrod, your advice based on your career as a contractor is very much appreciated. I certainly won't get invested, but I will be sure to discreetly inform the PM and my salaried coworker via email just prior to the end of my contract.
    – splatto
    May 12, 2011 at 21:10
  • 7
    If someone insulted my work, I would ask for an apology. If they criticized it, I would not. I have had my work criticized on hundreds, probably thousands, of occasions; I have had it insulted very, very few times. If someone thinks that every criticism of their work is an insult, they have a serious problem. This applies to any line of work, or any social interaction ever. The same applies the other way: you have to criticize in a way that won't insult. There's no black and white terms of where you cross from criticism to insult, either.
    – corsiKa
    Jul 26, 2012 at 17:46

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!

  • This also sounds like a great approach to take. Thanks
    – splatto
    May 12, 2011 at 21:05
  • 5
    I agree here. Only the full-timers will be able to trigger a change. You don't need to convince the other contractor - you need to convince a stakeholder. They call the shots.
    – CAD bloke
    May 12, 2011 at 23:19

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?

  • He doesn't care - I had to write the code for that. I looked through here for an appropriate comment ahead of that method: stackoverflow.com/questions/184618/…
    – splatto
    May 12, 2011 at 15:37
  • 2
    He might not care but the project manager might if he sees potential performance complains from customers further down the road. At least if you can demonstrate potential future problems they can be anticipated and clean-up task can be schedule before it becomes too urgent. May 12, 2011 at 15:49
  • 2
    Depending on the amount of work involved (probably not too much), you might want to clone the dataset and convert the list field to a M:M. Then do some timing of various queries to demonstrate the performance difference. Hard numbers make for a very compelling argument, and are not subject to opinion. In addition to sticking it to the other consultant (who, IMNSHO, really has it coming to him), this makes for a professional, fact-based presentation. Jun 13, 2011 at 17:07

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.

  • I think that's a good attitude to take. Our PM has overheard one of our conversations about this, so in his silence I guess it's safe to say he doesn't want to take my suggestion.
    – splatto
    May 12, 2011 at 20:59
  • 1
    +1 - all care and no responsibility. Detachment will save your sanity.
    – CAD bloke
    May 12, 2011 at 23:22
  • 1
    My years of consulting are why I'm back to FTE. As a consultant you're either a warm body, in which case no one is going to listen to you. Or, you're a highly skilled expert, in which case if they don't listen to your advice, they're wasting their money. Either way, no reason to become emotionally attached to a project you won't be around to support.
    – msvb60
    May 13, 2011 at 14:19

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.

  • absolutely. If I was there and the guy came to me with a big bunch of whiny comments about the other guy, then you know who'd get marked down as 'not a team player'.
    – gbjbaanb
    May 13, 2011 at 9:35
  • I'm not sure what "immature and destructive" behaviour you refer to. I pointed out a big design flaw that I am working around, and then I inquired how I can best to minimize the influence on the next project of someone who makes poor design decisions and is moved to tears by advice on how something can be improved.
    – splatto
    May 13, 2011 at 19:44
  • 2
    ".....but I will be sure to discreetly inform the PM and my salaried coworker via email just prior to the end of my contract. – splatto May 12 at 21:10". The OP appears to be in a toxic workplace, however the kind of activity he has said he will be doing contributes significantly.
    – mattnz
    May 16, 2011 at 0:10
  • That was based on the advice found in answers that have received many more upvotes than your own. I'm happy to listen to your advice if you have any.
    – splatto
    May 16, 2011 at 14:53
  • This isn't a simple disagreement. The consultant has enforced a design thats dangerous to the client and he's lied about it being somethign that they teach in "masters degrees" (if that was really true, then I'd be raising serious queries about academic malpractice). Sure we have disagreements in our jobs. But there are some you absolutely have to make a stand on or your not doing your job properly. Yes he could be more tactful about it. But it actually sounds like this senior consultant is a threat to the clients business.
    – Shayne
    Jul 23, 2021 at 4:33

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.

  • 4
    he doesn't need to do all this, it is emperically accepted knowledge than a join table is the correct way and a multi-value field is NOT the correct way if you ask anyone who knows what they are doing.
    – user7519
    May 12, 2011 at 17:02
  • 3
    @Jarrod: But the number of people doing things the wrong way out of ignorance, cargo-cultishness, lack of a desire to learn, or bad mentorship is staggering. Sometimes a little evidence goes a long way.
    – JasonTrue
    May 12, 2011 at 18:14
  • doesn't mean he has to do all this work to prove something that thousands if not more people have already done, documented and written dozens of book on.
    – user7519
    May 12, 2011 at 18:15
  • Right, unless you need to keep working with that person (instead of around them) and want to deliver good code. If neither of those apply, you don't have to prove anything.
    – JasonTrue
    May 12, 2011 at 18:33
  • 1
    @Jarrod Roberson: You know that it's firmly established that the list is wrong and the join table is right, and I know that. The other consultant knows that his colleague is way upset about a perfectly reasonable design decision. May 12, 2011 at 20:18

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!

  • Great idea. I will start keeping such a log immediately.
    – splatto
    May 12, 2011 at 21:01
  • 3
    Commit your code comments - there is your log
    – CAD bloke
    May 12, 2011 at 23:16

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.

  • 1
    I would argue the project manager not allowing Code Review even with a close deadline is the biggest problem. Eventually this design choice will hurt their project, he will eventually be blamed and be asked, "how did this issue not get noticed in your peer and code reviews?"
    – Ramhound
    May 12, 2011 at 16:02
  • 3
    @Ramhound No, what will most likely happen is that the PM will say that it was the consultant's fault and they'll never get hired again. It's easier to stay inside once you're inside. May 12, 2011 at 16:25

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.


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.


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.

  • Actually, the other contractor is the most junior guy despite being a year my elder. I'm simply the most recent hire
    – splatto
    May 12, 2011 at 20:58
  • 2
    Whats the big deal about "a year my elder". I work guys 10 years my junior who are technically much better programmers than me - me recognising and accepting that makes be a better programmer on par with them. Last time a calender year was a big deal was when I was a teenager.
    – mattnz
    May 13, 2011 at 20:31
  • Sadly mattnz, you miss the point. I'm painting a picture of the personality I must deal with. Somehow, you understand that I read some sort of societal programmers hierarchical significance into that. Most reasonable people with a grasp of the language would see that this fits the other guy. I'm sorry you're so bitter but I appreciate your attempts to help nevertheless.
    – splatto
    May 16, 2011 at 14:57
  • No (too) bitter, just suggesting that on balance it's probably easier to accept the bad design decision and work with the team to get the best outcome. I am sure you know quote "God give me the strength... the serenity... and wisdom...." This is seems to be one of those times to be wise.
    – mattnz
    May 17, 2011 at 3:51
  • 1
    No. Its an objectively terrible design and I would fail and probably scold any student who submited this in an assignment. It creates queries the optimiser can't reason about, it propogates corruption ito the entire index (which is stored as comma separated values. You trash that field, and you lose it all.), it would be dreadfully slow to use, and be unnecissarily complicated to query. It literally has no upside. I've seen this design before and I've thrown a fit about it everytime because its straight up dangerous and ignorant.
    – Shayne
    Jul 23, 2021 at 4:29

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.