locked
How to tell a programmer he is wrong? RRS feed

  • Question

  • Hi

    Here is the situation. Currently I am developing a solution that works with... whatever it doesnt matter. The point is that I designed the whole structure of this application. Now all I had to do is implement certain clases, add data objects etc. basicaly the guidlines were set now i only have to follow them. Unfortunately we need to finish this project fairly quickly. So Last week my boss hired another guy from another project to help out. And I described the current design and what he has to do (pretty acurately in my opinion). And Of course a week later (he will be working for 6 weeks here) we are having a meeting and this guy unveils his "better" design. Not only that. He was such a gentleman that he already implemented that design in the part that he was supposed to complete.

    Of course I wasnt too pleased about that cuz lets face it - we didnt ask him to reinvent the system (or a part of it) just help us to finish it. Of course I guess i could just ask him to redo the whole thing. But the problem is that his solution is not that bad (it has its plusses and minues) and i dont want to be rude either. But I dont think i can support his ambitions just cuz in the end the system will have two pretty unconsistent parts. 

    So my question is this: What would you say to the guy? How to explain to him that this isnt gonna work (even though i appreciate the effort and idea)? 
    Im sure there are plenty of people who have more experience in programming than myself therefore maybe you can give some arguments or just angles (like general design rules) that i probably have missed (that i could use to make him understand that I am right without making him hate me for the rest of my life).

    P.S. I myself am a developer and have done the same crime before (maybe not on the same scale though). But this is the first time Im in a position of programmer who has to watch how his design is being raped by someone else :)

    P.P.S. I know this is more a General than a Visual Basic question.

    Cheers!
    Monday, January 25, 2010 11:47 AM

Answers

  • It’s not really a matter of who’s right and who’s wrong.  It’s a matter of how what he’s done affects the ability of your team to deliver the project on time with the functionality and features required to meet the specifications.  His design may be better than yours, it may even be brilliant; but if it causes more work for the team (jeopardizing your ability to meet requirements and due dates), he’s done you no service.

    For future reference, make sure when you get new team members, they know where you are in the software development process.  Also, make sure the new team member knows what their role is and what you expect him/her to do.  In this case, the new team member is a "programmer" and you expect him to code from the design you present. 

    Seems you’re project is in “coding” phase with design/architecture complete.  Any changes to design/architecture must go through the project leader/architect at this point.
    • Edited by BarbaraR Monday, January 25, 2010 4:44 PM
    • Proposed as answer by DiegoCattaruzza Tuesday, January 26, 2010 8:58 AM
    • Marked as answer by nsp_ Tuesday, January 26, 2010 2:52 PM
    Monday, January 25, 2010 4:33 PM

All replies

  • Nothing, and if the project is not ready in time or there are bugs. 

    Yea, it is than easy to tell your boss that a main reason was the redesign of the wheel while it was almost ready.

    And if is ready on time without any bug, (the last chance is low) then learn from it. 


     
    Success
    Cor
    Monday, January 25, 2010 12:03 PM
  • @naurispunk

    Don't stress yourself....be a gentle man...

    Teste the program before him. That is the only way to let him know the problem and " How to explain to him that this isnt gonna work (even though i appreciate the effort and idea)"

    If u just tell him without proving it , the guy may think that, you have somthing against him.

    I would think that!

    Just Be Humble Malange!
    Monday, January 25, 2010 12:08 PM
  • At the end of the day, it comes down to a simple double question: Who is in charge and what is needed in order to complete the program?

    We all have come across those guys who join a project temporarely and know everything better. Yet, the problem is that they are gone in a few days / weeks but we have to continue with the work on that project ...

    I wouldn't stress about the question of 'being rude' - in order to complete the task, you sometimes have to!
    He did not join your project to 'take over and change everything' but to help out. You will have to tell him this, one way or another - your project is in danger otherwise! Give him an exact description of what he needs to do - if he refuses, tell your boss that working with him is slowing down the progress and you might be better off without him ... !

    Where can be only one lead!

    (Damn, I should go and charge Dr. Phil, lol)


    Listing SPEC's is not a review !!! :-)
    Monday, January 25, 2010 12:21 PM
  • But how do you prove that thing? Basically it just two different parts that do the same job, just differently.

    I kind of stated my point as if it is decided that he will have to redo his job. Maybe there are someone who would let him do his thing it the part he is developing? Just wondering 

    P.S. cuz hes a good programmer; its not like the stuff he does is not working, although i havent tested it yet myself so will see. And thats another thing -What if the code has errors (and it will obviously) - he is only here for a while and there is a good chance that i will be the one who will have to solve them.

    Cheers!
    • Edited by nsp_ Monday, January 25, 2010 12:32 PM Misunderstood the point
    Monday, January 25, 2010 12:28 PM
  • Good point. I guess I would hate myself too :) Well, it's not like we are best friends or anything.

    I kind of stated my point as if it is decided that he will have to redo his job. Maybe there are someone who would let him do his thing it the part he is developing? Just wondering 

    P.S. cuz hes a good programmer; its not like the stuff he does is not working, although i havent tested it yet myself so will see. And thats another thing -What if the code has errors (and it will obviously) - he is only here for a while and there is a good chance that i will be the one who will have to solve them.

    Cheers!

    I cannot understand your point now. for me the guy is really good and you are just J...

    what do you think?
    Just Be Humble Malange!
    Monday, January 25, 2010 12:31 PM
  • I cannot understand your point now. for me the guy is really good and you are just J...

    what do you think?
    Just Be Humble Malange!
    Well I corrected the post (cuz i think i misunderstood you). 
    The bottom line is this:
    a)Im curious- what arguments other people use to argue that this type of thing is wrong (implementing different design rules in same application)?
    b) I am saying that it's is not his lack of experience that bothers me but the fact that he is appling new design rules to a design that is already in use in other parts in applicaion.
    c) I was asking if there is someone who would let a programmer do his thing without making him redo the stuff he has already done.
    d) English is not my first language :)

    Cheers!
    Monday, January 25, 2010 12:50 PM
  • I think you should work from point b). You can tell him that you appreciate the effort he put into the new design but that it isn't consistent with the design of the current implementation. Also, there may be some things that you can implement from his design that are worth considering, without changing the design, so be willing to accept his input and ideas. Tell him about the parts of his design that you do like and ask him how he can work his design into the existing design, without having to re-write the code. 

    You can still encourage him, but don't tell him he is wrong. Just be firm that the design decisions were already made by those responsible for managing the project.


    Paul ~~~~ Microsoft MVP (Visual Basic)
    Monday, January 25, 2010 3:32 PM
  • "...And I described the current design and what he has to do (pretty acurately in my opinion). And Of course a week later (he will be working for 6 weeks here) we are having a meeting and this guy unveils his "better" design. Not only that. He was such a gentleman that he already implemented that design in the part that he was supposed to complete.

    Of course I wasnt too pleased about that cuz lets face it - we didnt ask him to reinvent the system (or a part of it) just help us to finish it. Of course I guess i could just ask him to redo the whole thing. But the problem is that his solution is not that bad (it has its plusses and minues) and i dont want to be rude either. But I dont think i can support his ambitions just cuz in the end the system will have two pretty unconsistent parts."

    1.  If he was working for you how did you not know?

    2.  He should not have unveiled his new design in the manner he did, regardless of how good it was.  My response would have been to remove him from the project immediately.  What message are you sending the other team members if you don't.  It is hard to put the genie back in the bottle.

    3.  "Our" code / design often becomes prideful making it hard to be criticized.  It should be hurtful if someone tells you that you are ugly, but it shouldn't hurt if someone says your code / design is bad.  The latter should be discussed on all of the merits.

    Looking for work - Zip 65101 http://www.vbforums.com/showthread.php?t=552774
    Monday, January 25, 2010 4:05 PM
  • "...And I described the current design and what he has to do (pretty acurately in my opinion). And Of course a week later (he will be working for 6 weeks here) we are having a meeting and this guy unveils his "better" design. Not only that. He was such a gentleman that he already implemented that design in the part that he was supposed to complete.

    Of course I wasnt too pleased about that cuz lets face it - we didnt ask him to reinvent the system (or a part of it) just help us to finish it. Of course I guess i could just ask him to redo the whole thing. But the problem is that his solution is not that bad (it has its plusses and minues) and i dont want to be rude either. But I dont think i can support his ambitions just cuz in the end the system will have two pretty unconsistent parts."

    1.  If he was working for you how did you not know?

    2.  He should not have unveiled his new design in the manner he did, regardless of how good it was.  My response would have been to remove him from the project immediately.  What message are you sending the other team members if you don't.  It is hard to put the genie back in the bottle.

    3.  "Our" code / design often becomes prideful making it hard to be criticized.  It should be hurtful if someone tells you that you are ugly, but it shouldn't hurt if someone says your code / design is bad.  The latter should be discussed on all of the merits.

    Looking for work - Zip 65101 http://www.vbforums.com/showthread.php?t=552774


    Hi dbasnett,

    I agree that if someone, for whatever reason is causing delays in a project
     then they should be removed immediately and without argument.

    The person(s) concerned should be told the error of their ways if an argument does start and in my opinion,
     be given one more chance by the project manager or "the boss" who is overseeing everything.
     Otherwise asked to help out on another project or else help with the design - startup of a new project.


    At the end of the day, decision(s) have to be made!! Don't let anyone hold a project back, deadlines should be set!!


    I bet event the development team(s) at Microsoft behind Windows 7 , OFFICE and their other products all have to work to deadlines.


    Regards,

    John
    Monday, January 25, 2010 4:24 PM
  • It’s not really a matter of who’s right and who’s wrong.  It’s a matter of how what he’s done affects the ability of your team to deliver the project on time with the functionality and features required to meet the specifications.  His design may be better than yours, it may even be brilliant; but if it causes more work for the team (jeopardizing your ability to meet requirements and due dates), he’s done you no service.

    For future reference, make sure when you get new team members, they know where you are in the software development process.  Also, make sure the new team member knows what their role is and what you expect him/her to do.  In this case, the new team member is a "programmer" and you expect him to code from the design you present. 

    Seems you’re project is in “coding” phase with design/architecture complete.  Any changes to design/architecture must go through the project leader/architect at this point.
    • Edited by BarbaraR Monday, January 25, 2010 4:44 PM
    • Proposed as answer by DiegoCattaruzza Tuesday, January 26, 2010 8:58 AM
    • Marked as answer by nsp_ Tuesday, January 26, 2010 2:52 PM
    Monday, January 25, 2010 4:33 PM
  • Well said Barbara.

    Looking for work - Zip 65101 http://www.vbforums.com/showthread.php?t=552774
    Monday, January 25, 2010 4:36 PM
  • Hi BarbaraR,

    Extremely well put across I will say too Barbara, thank you for your well thought out contribution to this thread. :-)

    I would like to quote that post in the future if I may? I could not say it any better. :-)
    Your 2nd vote is from myself.


    Regards,

    John
    Monday, January 25, 2010 4:50 PM
  • 1.  If he was working for you how did you not know?
    Well, I didn't check his subversion commits on daily basis so I guess that is why I didnt notice. That and the part he is working on doesnt affect much of the rest program. 
    It's like we have to build 3 nice family homes on one street. 1 is almost finished and he is building the second one. Only it isnt a nice family house - it's a office building :)
    P.S. Not that I have something against office building. Someone could live there too. But that is not what I had in mind :)

    Cheers!
    Tuesday, January 26, 2010 7:55 AM
  • Some times a rect line is not the fastest way to achive your objetive.

    All programmers have our way to work, and it could be fine or wrong, but if the objetive is achieved....

    Naurispunk, try to talk with him/her and explain your idea....



    Si la respuesta te ha sido util Marcala como Respuesta o Votala.
    Mi Blog: Jtorrecilla
    Tuesday, January 26, 2010 8:01 AM
  • 1.  If he was working for you how did you not know?
    Well, I didn't check his subversion commits on daily basis so I guess that is why I didnt notice. That and the part he is working on doesnt affect much of the rest program. 
    It's like we have to build 3 nice family homes on one street. 1 is almost finished and he is building the second one. Only it isnt a nice family house - it's a office building :)
    P.S. Not that I have something against office building. Someone could live there too. But that is not what I had in mind :)

    Cheers!


    I think you're enjoying this a little too much.  While I, like yourself, have been on both sides of the table when it comes to this scenario - a couple of factors really stick out and begs for some consideration.


    The biggest one is, how new he is.  Since he has only been with you for 6 weeks.  Maybe he didn't intend on redesigning the application?  Maybe he produced something the way he knows, incorporated what you showed him and never intended on "unveiling a better design."  It may just be that he was either seeking education/feedback or intentionally over explaining what he brought to the table for constructive criticism.

    If this is the case - you should be commending him rather than ridiculing.  After 6 weeks, most new people I've had to work won't even try.  They will ask the same questions to a handful of people until someone stops what they're doing and shows (read: "does it for") them.  The way I see this is - he hit the ground running, took initiative and came back with something that, in your words - "is not that bad."  Maybe the brash tone of your story isn't so much anger or disappointment with him and the project...  Maybe it's a concern with him and you - just throwing it out there, but maybe you're feeling slightly threatened?


    No matter what the root problem is; one thing is for certain.  Someone (maybe not you specifically) had to know that what he was going to provide wouldn't be "perfect" or ultra-compliant.  And when you go back to him; do not use definitive words like "wrong" or "right."  Unless you want to take what should have been an expected hurdle and turn it into a blamestorm session; you absolutely have to sit down with him, assess what he brought to the table and explain what needs to be changed.  And in the "plus areas" of his code - throw him a bone.  Commend him on the good idea, but then explain how it wouldn't be consistent.  If he's adamant - simply ask him to keep it in mind and offer it up as a future enhancement...  When it can be added to the goals.

    Tuesday, January 26, 2010 8:49 AM
  • First of all thank you for reply. It's always nice to come across some new view points.

    "The biggest one is, how new he is.  Since he has only been with you for 6 weeks.  [..]  It may just be that he was either seeking education/feedback or intentionally over explaining what he brought to the table for constructive criticism."

    1) He is not a new programmer. We are roughly the same age and started working in this company pretty much at the same time. Six weeks is probably time he is scheduled to work with our project (as to complete his task). That term is important when I speak about his overall involvement in this project. I didn't say that to put him down in any way.

    "Maybe he didn't intend on redesigning the application?  Maybe he produced something the way he knows, incorporated what you showed him and never intended on "unveiling a better design.""

    2) This is not true. The part he has to complete was already started (besides base structure, there were some functions already implemented). He rearanged those functions (removed from original classes and interfaces and put them where I never intended them to be).

    3)  Of course there is always chance that I didnt explain the situation or he misunderstood. But the fact is when I told him that his design is different from original (mine) he instead of saying that he simunderstood he started to argue how his design makes more sense (to him). Nevermind the fact that the original was already in place (implemented in other parts) and satisfied the specification.

    "The way I see this is - he hit the ground running, took initiative and came back with something that, in your words - "is not that bad."  Maybe the brash tone of your story isn't so much anger or disappointment with him and the project...  Maybe it's a concern with him and you - just throwing it out there, but maybe you're feeling slightly threatened?"

    4) Threatened is not the right word. More like betrayed :) Yes, when I first heard what he had done I was pissed. I mean who wouldn't. I create a design that I have been working for a good while and along comes this guy (I say comes along, he actually works in the same company, building, different project and I meet him every day) and without saying anything after a week my job is not good enough for him.

    5) Having said that, I know that how it feels to be in his shoes. Moreover, as I said this is pretty much the first time someone has done this type of thing with my design (which I the main reason why I started this thread I guess; to see what other people think). So I'm not trying to ruin his day or walk all over his initiatives.

    "Someone (maybe not you specifically) had to know that what he was going to provide wouldn't be "perfect" or ultra-compliant. "

    6) That's true

    " And in the "plus areas" of his code - throw him a bone."

    7) Throw him a bone? And you accuse me of having a brash tone :)



    Cheers!
    Tuesday, January 26, 2010 11:17 AM
  • Sure thing @John Anthony Oliver.
    :)
    Tuesday, January 26, 2010 3:06 PM
  • A lot of good inputs here.

    One thing that you might consider is to offer that his design is good but, given there's no time, that it'll be considered for an upcoming new version of the software. Even if you're not sincere about that, nobody's ego is bruised and you've been the "gentleman" in the process by offerring a win-win to him.
    Tuesday, January 26, 2010 4:14 PM
  • Sure thing @John Anthony Oliver.
    :)


    Well said Barbara. 

    This scenario reminds of a gentlemen who we had as part of our team around a decade ago.  He wasn't the best, nor the most brilliant, but he could finish stuff on time and deliver....provided he was working alone.  The problem with this guy wass that all of that good stuff went out the window when it came to work with others. 

    He knew only one way, his way, to do things.  You could ask him to follow this route, he would agree, but would still follow his own path.  This would force everyone to scramble to finish on time.  Successful projects only served re-reinforce his justification for his actions.  He had even acquired a nickname.  Behind his back he was known as "The Undertaker".

    He had burnt one time in a fashion just like the OP.  forced me to work overtime to redo stuff his way.  No choice in the matter.  He had actually went as far as to delete ALL of the stuff I had written.  Naturally, complaints on my part reflected badly upon me because the project was a success.  I vowed to myself that that would never happen again.

    Opportunity knocked!  I had a chance to return the favor, and took full advantage of it.  He was stuck.  I was asked to assist.  I re-wrote the code, and deleted all of his stuff.  He did not understand how it worked, and I didn't care.  I was long gone.  "The Undertaker" had met his match.  Other people whom he had burnt along the way were asked to assist him at one point or another.  Everyone deleted his stuff.  He was eventually demoted and later fired.

    I would not recommend anyone to purposely sabotage the work of a co-worker.  But, it is a dog-eat-dog world and we encounter co-workers who do sabotage or undermine the work of their colleagues.  Do not attack them, for justice is always served.  In these situations I advise restraint, and "do unto others as you would have others do unto you ". 

    I take that to also mean "do unto others as others have done unto you" , which is equivalent to, "An eye for an eye, and a tooth for a tooth ."

    Rudy  =8^D

    Mark the best replies as answers. "Fooling computers since 1971."
    Tuesday, January 26, 2010 4:54 PM
  • Hi. 

    Thanks to everyone who took their time to answer.

    P.S. As I said before this is more General that Visual Basic question. On that note does Microsoft of anyone for that matter has a forum for this type of questions?

    Cheers!
    Wednesday, January 27, 2010 10:57 AM
  • Generally, no.
    You might try the Sandbox, though.

    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, January 27, 2010 1:55 PM
  • Hi. 

    Thanks to everyone who took their time to answer.

    P.S. As I said before this is more General that Visual Basic question. On that note does Microsoft of anyone for that matter has a forum for this type of questions?

    Cheers!

    Not really since this has actually nothing to do with programming but with the interaction of people. The MSDN Forums are designed to discuss language specific programming techniques and ask for help in case you get stuck. As you might have noticed, this alone fills up the boards already with thousands of posts per category.

    The question on how to behave yourself (or others) in a team just does not really fit in this system, yet, it is nothing wrong with asking such questions. Just don't be disappointed if your thread gets sooner or later deleted or moved to the OFF-TOPIC (read-only) section.
    Listing SPEC's is not a review !!! :-)
    Wednesday, January 27, 2010 3:14 PM