Knife in my back
-
Has your PM got a solution? Even if it is to say that you'll be able to patch in a months time, he must go with the solution, not the problem. Otherwise he really is fucking you over. In his shoes, I would first want tot know the extent of the issue and what the effort is to resolve it. Only then would I go to the client. I would give credit to 'the team' for finding this issue 'while testing an unrelated change'. The pressure is reduced because the client then knows that you guys are on the ball and ahead of them. Simples.
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
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)
-
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
I claim that, but it's true ;P doing some now.
-
That's not what having a solution means. It means, does he have a suggestion to offer to the client with regards to this behaviour - it's not his job to code, it's yours.
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 point exactly. The PM should at least know what the issue is and how it will be addressed. It is my opinion, and I do not claim humility here, that if he cannot have these two pieces of information and is not capable of communicating them then he is in no position to be a PM. The PM is the bridge between the team and the client, it is his job to reassure the client and instil confidence whilst protecting the team from any shit that may come their way.
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
-
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
well, that doesn't help you any.
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) -
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