How to break it to your boss...



  • I recently got the task to overhaul a piece of communication code between a DAC and a PC. Basically, I was told the code was tested and it worked, but now they wanted to switch a setting and I should implement it. Boss said he wasn't so knowledgeable in the communication (ISO/OSI) department, so I basically assumed I had free hand to change on that level.

    Looking at the code, I saw that the whole thing was scavenged from an earlier project and quite bloated for the current task. So I sketched up a refinement.

    I showed it to my boss for okaying, but when I mentioned that the code was a bit on the bloated side, he suddenly changed his story. I got told that the basic communication was well-tested and should not be changed - my task had been to add another layer on top of it. Ah well, my fault, shouldn't have assumed. So I went on my merry way.

    Then I found something odd in the code.

    Well, when I say odd I mean WTF-level - I can't really post it as it's neither spectacular nor anonymizable enough to post on WTF, but let's just say that it compromises all of the data sent over this link, and is almost definitely a bug, not something fiendishly clever (you never know...).

    But the main problem that I found out was the name of the programmer. And... you guessed it... it's bossman.


    I can't simply fix the code/write it correctly in the bit I'm changing anyway and gloss over it. If the data coming out of the system is suddenly different, this will affect all of the algorithms written on the other side unknowingly made to deal with the basically incorrect data - and as far as I know, it's not just a matter of fixing a calibration somewhere either. So I can't get around having to break it to him somehow.

    Does anybody have good ideas on how to do that and keep my job at the same time given that I already must have offended him once carelessly letting slip that I thought the code was bloated?

    I'm trying to get as much to back up my claim of the code being odd and the data being falsified for now, and am thinking of getting someone to back me up, but who would be good for that? Someone on the same level as bossman? I'd get someone who has worked with the code before but I'm not sure if they work at the company any more...



  • being afraid of your boss is bad, m'kay. He is paying you because you can program, because you know this stuff. Or at least he thinks you do. Either way, by not telling him your not doing your job, he has given you the responsibility for that functionality, if it's not functioning it's your fault, no matter who wrote the code, or what your boss or co-workers might have said about the bug-free-ness of the code. 

    Out of the top of my head i can only think of one program that can claim to be quite bug free. Which is Tex, and you can get money for finding bugs. Bugs happen, having a program be fully tested does not mean that there are no bugs, it just means that you haven't found them, and you can be fairly sure that in the functionality you tested there are none or they only show up in very peculiar cases.

    So basically just tell him. If your a chicken, ask him too look at a piece of code that you "don't understand", or whatever. By not telling him, your just digging a pit for yourself, and lowering the quality of the product. 



  • I agree with stratos for the most part. I would take the dodgy code to your boss, saying you "don't understand this piece... surely this would give strange results?.. blah". He can hardly take offence if you are asking a question. Given your existing relationship with him, you have to walk on eggshells, but you need to get it done.



  • Just tell him.

    Don't go with the overplanned politics. Don't waste energy on that path. 

    Saying that some code is bloated is not offending anyone, it's optimizing. 

    Saying that he wrote buggy code is not offending him, it's fixing it. That's one of the reason you were hired, right?

    Unless your boss is a dick, there should not be any problems. It's just a job task. You are both grown professionals. Keep it professional and everything should be fine.

    On the other hand if your boss is a childish prick, then you are screwed, and will have to start to look for a new job.



  • I totally agre with the comments above. However, this seems to fall into the "choose your battles..." category. If it's not important; do the job, cash your paycheck, and save the battle for more important issues.



  • @ajp said:

    I totally agre with the comments above. However, this seems to fall into the "choose your battles..." category. If it's not important; do the job, cash your paycheck, and save the battle for more important issues.

     

    Battle? Dude, that is a job not a war. You are not suppossed to battle, you are suppossed to work. 

    Peace brother!

     



  •  Most of the posts in this thread seem to ignore human nature and downplay office politics too much.  I hate that kind of stuff as much as the next guy, but programmers, and bosses have egos, and it's a good thing not to step on those egos to hard.  I would tell him about it, and show him why it has to be changed, but I would be very careful in the future about cavelierly refering to code as "bloated" or WTF when you don't know who wrote it.  There is a pretty good chance that at least some of it was written by people that you work with.  



  • @tster said:

     I would tell him about it, and show him why it has to be changed, but I would be very careful in the future about cavelierly refering to code as "bloated" or WTF...

     

    Easy solution to avoid/minimize politics here: stick to requirements. If the code - pretty or not - meets the requirements or works in the required context, you unfortunately just have to "suck it up". If the code doesn't meet requirements, then you get to change it because it's not *doing* what it should. Unless there is a really good reason to change things for style (e.g., regulations or something), sometimes you just have to live to work in an environment that doesn't match your preferences.

    (As an aside, I would only refer to something in code which implements some functionality beyond what is required as "bloat"; an 'inefficient' implementation that works is not bloat, it's just inefficient. I will qualify that as my personal opinion though and not any kind of binding definition *grin*)



  • @too_many_usernames said:

    @tster said:

     I would tell him about it, and show him why it has to be changed, but I would be very careful in the future about cavelierly refering to code as "bloated" or WTF...

     

    Easy solution to avoid/minimize politics here: stick to requirements. If the code - pretty or not - meets the requirements or works in the required context, you unfortunately just have to "suck it up". If the code doesn't meet requirements, then you get to change it because it's not *doing* what it should. Unless there is a really good reason to change things for style (e.g., regulations or something), sometimes you just have to live to work in an environment that doesn't match your preferences.

    (As an aside, I would only refer to something in code which implements some functionality beyond what is required as "bloat"; an 'inefficient' implementation that works is not bloat, it's just inefficient. I will qualify that as my personal opinion though and not any kind of binding definition *grin*)

     

    I somewhat agree with that, although i would like to extend "requirements" to more then just functional correctness and include proper coding practises.  Refactoring working, but hackish old code is just as important as writing new code. It's the only way to fight code rot. (wel besides from throwing away old code)

Log in to reply