Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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.

share|improve this question

migrated from stackoverflow.com May 12 '11 at 15:39

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, MichaelT, david.pfx, GlenH7, Bart van Ingen Schenau Jun 10 at 10:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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 '11 at 0:00
1  
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 at 9:53
    
This is a rant. VTC. –  david.pfx Jun 6 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 at 17:52

13 Answers 13

up vote 35 down vote accepted

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 definately 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.

share|improve this answer
4  
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. –  Wayne M May 12 '11 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. –  Jarrod Roberson May 12 '11 at 17:55
4  
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. –  Wayne M May 12 '11 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 '11 at 21:10
3  
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 '12 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!

share|improve this answer
    
This also sounds like a great approach to take. Thanks –  splatto May 12 '11 at 21:05
3  
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 '11 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?

share|improve this answer
    
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 '11 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. –  FrustratedWithFormsDesigner May 12 '11 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. –  Peter Rowell Jun 13 '11 at 17:07

First you are correct this is a very poor design. Do not ever apologize for professionally disagreeing, aplogize 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 professinal disffernce 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 appropraite 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 delimeted 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.

share|improve this answer
3  
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. –  Jarrod Roberson May 12 '11 at 17:02
1  
@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 '11 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. –  Jarrod Roberson May 12 '11 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 '11 at 18:33
    
@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. –  David Thornley May 12 '11 at 20:18

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.

share|improve this answer
    
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 '11 at 20:59
1  
+1 - all care and no responsibility. Detachment will save your sanity. –  CAD bloke May 12 '11 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 '11 at 14:19

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!

share|improve this answer
    
Great idea. I will start keeping such a log immediately. –  splatto May 12 '11 at 21:01
2  
Commit your code comments - there is your log –  CAD bloke May 12 '11 at 23:16

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.

share|improve this answer
    
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 '11 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 '11 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 '11 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 '11 at 14:53

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.

share|improve this answer
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 '11 at 16:02
2  
@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. –  Michael Todd May 12 '11 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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 '11 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 '11 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 '11 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 '11 at 3:51
    
Absolutely. I understand I will be starting the next project in the very near term while my colleague is finishing up this one. I'm already thinking about how best to design the database, and how to make sure others are convinced that is the best way as well. –  splatto May 17 '11 at 20:25

Actually, he might very well be right. What he did is what I would call 'inlining' a relationship.

Imagine that you know there is a reasonable limit to the number of properties that a car can have, you can definitely put those properties in as a column of each car row.

A separate relation table is supposed to be for the case where the number of properties cannot be anticipated.

How is his design better, several reasons: - Because of inlining, his read will be massively better than yours. (Won't have to read the relationship table's index) - When you add and remove properties to the car, the location of the row for a relationship can be fragmented throughout the relationship table. Again, affect read time if you eagerly fetch the properties.

share|improve this answer
    
Kindly let me know why my answer is wrong, when you vote my answer down. Thanks!! –  InstructedA Jun 6 at 7:36
    
per my reading, this is merely a technical note commenting a particular example of the disagreement. It looks totally tangential top the question asked, which seems to be about how to handle such disagreements –  gnat Jun 6 at 8:00
    
Got it, you meant this is more non-technical than it is technical. Ok –  InstructedA Jun 6 at 8:03
    
exactly. If the asker used another code example, this wouldn't really change much in the question, focusing solely on analyzing it would rather distract site visitors instead of helping them to learn about the problem and solutions –  gnat Jun 6 at 8:06

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