Knife in my back
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
It is the PM's job to advise clients of bugs. It's entirely normal for testing sign off to require complete disclosure of outstanding features that need to be either signed off as not blocking the release, or the sign off cannot be achieved. If you have a bug, the client has to make the decision as to whether the defect can be lived with - this is, after all, something they are going to have to live with. Just because you don't want to fix it, doesn't mean that he's wrong - quite the opposite in fact. Your PM would be derelict in his duties if he didn't do this. Look at it this way, if you were paying a lot of money for a system, would you be happy when you found out that there was a known defect and you hadn't been told about it? I know I wouldn't.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
It is the PM's job to advise clients of bugs. It's entirely normal for testing sign off to require complete disclosure of outstanding features that need to be either signed off as not blocking the release, or the sign off cannot be achieved. If you have a bug, the client has to make the decision as to whether the defect can be lived with - this is, after all, something they are going to have to live with. Just because you don't want to fix it, doesn't mean that he's wrong - quite the opposite in fact. Your PM would be derelict in his duties if he didn't do this. Look at it this way, if you were paying a lot of money for a system, would you be happy when you found out that there was a known defect and you hadn't been told about it? I know I wouldn't.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
it's not about me not wanting to fix it or the customer to live with that "undocumented feature" explanation here[^] I'm already working on it and the customer will get further updates anyway. Also does the software what it is supposed to do. I don't like bugs, but I'm fine(well, just kind of...) if we reveal some unexpected during tests - they get documented right away and will be fixed asap. The PM is simply risking the acceptance test and blaming it on me if it fails. A base of confidence is currently not included here.
regards Torsten When I'm not working
-
Nagy... All I read was yada yada yada yada because in this case it is clear that the PM wants to knife over (for lack of the other word) our fellow CPian. I am sure there is politics involved in here and I am sure the PM knows all that...
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
politics? I'm not sure. The PM knows that I have my own understanding and will speak out - I'm not hired to follow like a lemming. When I see a problem or have to change some - I'll tell. And do. And I have to do, lot of basics are still missing here.
regards Torsten When I'm not working
-
I think everyone claims to have done C in the past.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Anyone can program, but not everyone is a programmer[^] great article by the way.
regards Torsten When I'm not working
-
TorstenH. wrote:
He could just have stab me with a big knife.
This is less messier and produces the same results.
Too much of heaven can bring you underground Heaven can always turn around Too much of heaven, our life is all hell bound Heaven, the kill that makes no sound
...but the chalk lines on the carpet won't wash off that easy. Company looses a PM and the best developer it ever had.
regards Torsten When I'm not working
-
it's not about me not wanting to fix it or the customer to live with that "undocumented feature" explanation here[^] I'm already working on it and the customer will get further updates anyway. Also does the software what it is supposed to do. I don't like bugs, but I'm fine(well, just kind of...) if we reveal some unexpected during tests - they get documented right away and will be fixed asap. The PM is simply risking the acceptance test and blaming it on me if it fails. A base of confidence is currently not included here.
regards Torsten When I'm not working
You seem to be missing the point. It should be their decision, not yours. The PM is giving them the information they need - pure and simple.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
-
You seem to be missing the point. It should be their decision, not yours. The PM is giving them the information they need - pure and simple.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I would agree if it is a real failure, something that is false, not working, not like described in the contract. I would take the blame (if it is on me) and work it out. But it isn't. In fact the customer would not even notice it, because the app is running fine & stable. The customer will make it a point when the PM pokes the customers nose to it. By now I have 32 classes on my commit list X|
regards Torsten When I'm not working
-
Time to pass the keyboard to him and walk out of the door.
Software Kinetics Wear a hard hat it's under construction
Metro RSSNO! My Keyboard&Mouse is my personal stuff ;P I'm a bit picky on the tools as I use them all day long. But I'm actually able to do that. Grab my stuff and walk away.[^]
regards Torsten When I'm not working
-
It is the PM's job to advise clients of bugs. It's entirely normal for testing sign off to require complete disclosure of outstanding features that need to be either signed off as not blocking the release, or the sign off cannot be achieved. If you have a bug, the client has to make the decision as to whether the defect can be lived with - this is, after all, something they are going to have to live with. Just because you don't want to fix it, doesn't mean that he's wrong - quite the opposite in fact. Your PM would be derelict in his duties if he didn't do this. Look at it this way, if you were paying a lot of money for a system, would you be happy when you found out that there was a known defect and you hadn't been told about it? I know I wouldn't.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
I have to agree - it would be unprofessional, not to mention a legal liability, if the customer is not made aware of bugs known about at this stage. Can be a pain in the butt, but that's the nature of the game.
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
To assume any code is free of bugs is wrong. Customers should always be informed of any bugs that impact their usage of a product. As well they should be informed of any work around to avoid the issue and when it will be repaired. From a programmers point of view they should be trying to produce a product free of all bugs - impossible of course. To take a bug personally as you have as a stab in the back?
-
Well, it's a bug - or let's say a different behavior of the software. Nothing really wrong(*), but when he points it out to the customers, they will treat it like a failure. The customers are currently here in house testing. So I'll not touch the system and under no circumstances make any "updates" until it's really needed. *) The log in procedure is granting access to the (then empty) application when the password is false but the username correct (error dialog appears etc.). This is valid, as we have a "work offline" button with same effect on the log in dialog. The user can also log in/out via an internal dialog during work. The PM now wants me to change the complete log in procedure to not grant access when the password is incorrect. So far I have touched 25 (central!) classes still counting. No good idea to make this a "fast fix".
regards Torsten When I'm not working
TorstenH. wrote:
Nothing really wrong(*), but when he points it out to the customers, they will treat it like a failure.
Sounds like he's not trying to stab you in the back so much as promoting the priority of getting this mistake fixed. Since its intentional behavior, maybe he can't get it on the list of things to be fixed. Doesn't matter how much code you need to change to fix it.. if it's broke from the customer's point of view, then it's broke and needs fixing. Never forget that basic tenet of UI design -- the Principle of least astonishment.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
TorstenH. wrote:
My project manager is about to tell the customer about a bug in our current release - great idea.
No good idea, because the customer will not approve the system in that case.
He could just have stab me with a big knife.I don't understand the dynamics of that statement. The context suggests that you are working for a company. That company, not you, is responsible for fulfilling the contract. Perhaps you were expecting a bonus and you will not get it because the bug specifically fails to meet the contractual needs. If so sorry but then this is your problem. You should have known the contracted needs and implemented and tested for that (I presume from the above that there is no QA individuals.) That is how professionalism works. Maybe the project manager works for the customer? Then it is their professional responsibility to do exactly that. But perhaps there is some other dynamic in the above?
-
Well, it's a bug - or let's say a different behavior of the software. Nothing really wrong(*), but when he points it out to the customers, they will treat it like a failure. The customers are currently here in house testing. So I'll not touch the system and under no circumstances make any "updates" until it's really needed. *) The log in procedure is granting access to the (then empty) application when the password is false but the username correct (error dialog appears etc.). This is valid, as we have a "work offline" button with same effect on the log in dialog. The user can also log in/out via an internal dialog during work. The PM now wants me to change the complete log in procedure to not grant access when the password is incorrect. So far I have touched 25 (central!) classes still counting. No good idea to make this a "fast fix".
regards Torsten When I'm not working
If you have that many changes to do... then probably your design is not very good after all... You should have one class that do the authentication. If something is incorrect in the logic (like accepting a wrong password), you modify that class and all callers will then use the updated logic automatically.
Philippe Mori
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
The customer is the customer and is buying a product which performs (presumably) to his specification/requirements. Either it is a programming bug, or a failure in the specification, or of no importance at all. In any case QA should pick it up, the PM makes a decision as to it's importance and negotiates with the customer. If it's important enough for the customer to postpone acceptance, then it's got to be fixed. And he has to be aware of it.
-
My project manager is about to tell the customer about a bug in our current release - great idea. No good idea, because the customer will not approve the system in that case. He could just have stab me with a big knife.
regards Torsten When I'm not working
The PM may have just saved your job. If the customer is testing the software and finds a bug of this magnitude, they not only will reject the package, they may question the companies’ ability to perform. And move to a different vendor. By telling the customer about the issue, he is promoting the company as an honest supplier who has the best interests of the customer in focus. The loss of a customer could hurt you far more than the embarrassment of having an un intended feature pointed out.
Melting Away www.deals-house.com www.innovative--concepts.com
-
Has your PM got a solution? Oh, my PM doesn't even know how to start a Java related IDE. He is claiming to have done some C programming in the past. But haven't we all done that?
regards Torsten When I'm not working
It's irrelevant what your manager has or has not coded. In his current position, the qualifications he's required to demonstrate are quite different. The question posed by the previous poster doesn't even refer to a technical solution. Obviously your design is flawed, if you need to change code in so many places. Does shotgun surgery ring a bell? If not, you should go back to programming school, instead of bragging you're the best programmer the company ever had. You manager seems to know a lot more than you about properly handling a customer then you seem to know. The company may loose a programmer suffering from the "star programmer syndrome", it may even loose a customer, but the project manager obviously and always has to think about the customer's best interest, and the path of minimal damage. The loss of a star programmer who actually isn't one is not really a loss. The simplest way to loose a customer, OTOH, is to create the impression that you're worried more about covering your ass than about his problems. While telling the customer about such a big conceptional flaw might indeed cause the customer to leave, if the product is already in production, not telling him about the bug and causing the bug to hit head on in production later on could compromise the customer's whole business, and be sure the customer would take your company down with him. Judging from your posts, I think you're still pretty young, and not at all experienced in the business side of making software, right?
-
I would agree if it is a real failure, something that is false, not working, not like described in the contract. I would take the blame (if it is on me) and work it out. But it isn't. In fact the customer would not even notice it, because the app is running fine & stable. The customer will make it a point when the PM pokes the customers nose to it. By now I have 32 classes on my commit list X|
regards Torsten When I'm not working
And you still haven't stopped to think what's wrong with your design? You should definitely get fired. For your own good, please do read two essential books for any programmer: peopleware - a collection of essays on different aspects of software development, and the mythical man-month - another book of the same type, but written by a single author. Then go on to read The GoF patterns book, and Martin Fowler's Refactoring. You might want to stop considering yourself the best programmer the company had until then.