Project Manager asks for complete 100% confidence every time committing code(workplace.stackexchange.com)
workplace.stackexchange.com
Project Manager asks for complete 100% confidence every time committing code
http://workplace.stackexchange.com/questions/20098/project-manager-asks-for-complete-100-confidence-everytime-committing-code
30 comments
In my view, the idea of escalating the amount of work has a pitfall, which is this: The manager isn't really looking for 100% perfect code. He or she is looking for someone who promises 100% perfect code, and can thus be blamed when a bug crops up. If you don't fulfill this function, she'll find someone else who will. The boss wants to play the game of demanding unrealistic promises.
there is another pitfall, which is you come up with a scheme where every hour of dev is matched by 8h of testing and your managers reaction to this is "good".
(ps you probably should do 8h of testing for every hour of dev)
(ps you probably should do 8h of testing for every hour of dev)
I imagine this to be CYA on his part rather than magical thinking about how this question might improve productivity. "Yes, superior, the developer PROMISED this would not cause problems and gave me his 100% guarantee." It's a ticking time bomb.
No, the developer said that be believed it would not cause problems. They didn't give their 100% guarantee, only that they were sure it wouldn't cause any issues, to the best of their ability.
There's a big difference.
There's a big difference.
> The person in question probably comes from the mindset that setting an unachievable bar forces quality.
Funnily enough, today's Dilbert is about this. See http://dilbert.com/strips/comic/2014-03-09/
Funnily enough, today's Dilbert is about this. See http://dilbert.com/strips/comic/2014-03-09/
> I bet the PM already knows it's unreasonable to ask for 100% quality.
Yes. It sounds like a "give it 110%" sort of thing.
Yes. It sounds like a "give it 110%" sort of thing.
I would tell him that this can be achieved, roughly, as long as you follow a process like this one:
http://www.fastcompany.com/28121/they-write-right-stuff
Now, the question becomes if they can afford the headcount & time in order to implement such a process. Unless they are actually coding up avionics, defense systems, etc. the answer is probably "no".
http://www.fastcompany.com/28121/they-write-right-stuff
Now, the question becomes if they can afford the headcount & time in order to implement such a process. Unless they are actually coding up avionics, defense systems, etc. the answer is probably "no".
Typical cognitive dissonance playout. Know you aren't perfect, don't want to say you aren't perfect because you care more about what someone else thinks. Post on the Internet asking how to resolve dissonance. Get a bunch of answer saying find a new job. Continue to try to downplay your fears. Rinse and repeat.
Frankly, what this guy needs to do is to stop being afraid of what others think. Especially others who are clearly exploiting the guy's tendency to cater to others feelings. That may or may not involve finding a new job and/or boss, but if he doesn't fix himself, he'll just repeat it all over again.
I'm making blaming statements here, but I'm tired of narcissists fucking things up for the rest of us.
Frankly, what this guy needs to do is to stop being afraid of what others think. Especially others who are clearly exploiting the guy's tendency to cater to others feelings. That may or may not involve finding a new job and/or boss, but if he doesn't fix himself, he'll just repeat it all over again.
I'm making blaming statements here, but I'm tired of narcissists fucking things up for the rest of us.
You're probably right about the manipulative psychology of probing for and exploiting weaknesses. Absolutely disgusting, unprofessional, completely extraneous and non-work related. Very offensive and obnoxious to deal with.
Like has already been said, the right answer is to find a new job. That behavior is not the mark of a perfectionist, that's just someone who isn't cut out to be a manager. And they likely know it, too.
Also, just like columbo said, the next best answer to dealing with a micro-manager is to bury them in status reports, requests for approval on everything short of putting more paper in the printer, and as many emails every day as you can possibly justify. You're not ever going to convince them to stop micro managing, just try to give them what they think they want. They'll usually leave you alone after that. I don't know if it makes them face their own incompetence or what.
Also, just like columbo said, the next best answer to dealing with a micro-manager is to bury them in status reports, requests for approval on everything short of putting more paper in the printer, and as many emails every day as you can possibly justify. You're not ever going to convince them to stop micro managing, just try to give them what they think they want. They'll usually leave you alone after that. I don't know if it makes them face their own incompetence or what.
> That behavior is not the mark of a perfectionist, that's just someone who isn't cut out to be a manager. And they likely know it, too.
That's why they're a project manager. It's like being a rug doctor.
That's why they're a project manager. It's like being a rug doctor.
Good project managers are very valuable. Unfortunately they're not easy to find and evaluate.
Don't walk. Run.
So I think of this and then I think of
'THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.'
Could the poster be up for some nasty legal surprise?
'THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.'
Could the poster be up for some nasty legal surprise?
It is this kind of thing that makes me do what I can to avoid working for nontechnical people in a technical capacity.
"Sure, it'll just take me infinitely long to reach 100% confidence."
Some more context here would be useful. It's easy to assume the request is 100% ridiculous from the PM's side, but maybe the project has seen a significant decrease in quality recently. Has the bug rate skyrocketed? Have outages been on the rise? I'd expect a senior level person to be able to identify the warts and put a plan together on how to raise quality as a whole on the project. Educate them on what the right question to ask is, How can we improve quality, and have a well thought answer to follow it up with.
Just say yes (assuming you have done tests!) and have confidence in your changes. If it breaks something, put in some more tests to make sure it doesn't happen again, or find the bug unveiled by your fix, then correct this!
I should note that this is legally unenforceable. Bad place to work, but if it ever came to court, you just cite the halting problem to show that you cannot say in all cases that a problem won't be halted. What is being asked in impossible, so unenforceable.
I should note that this is legally unenforceable. Bad place to work, but if it ever came to court, you just cite the halting problem to show that you cannot say in all cases that a problem won't be halted. What is being asked in impossible, so unenforceable.
your courtroom defense would hold until the expert witness reveals that you have not been programming a Turing machine with an infinite tape...
lol! Only flaw there is that the halting problem works on modern computing also :-)
Nope, technically it has to be an infinite machine, otherwise it's just an over complicated finite state machine and proving termination in those is trivial.
I/O (except to bounded sources like disks) could probably save you, but the proof will be harder.
I/O (except to bounded sources like disks) could probably save you, but the proof will be harder.
There's two situations here:
You're being paid to write aviation quality code and the manager is incompetent about how to go about achieving that quality, or the manager is incompetent.
Also, just parse the requirements, she's asking for confidence that it won't break any features, not that the commit won't actually break any features.
Just be more confident.
Seriously though, find a new job.
You're being paid to write aviation quality code and the manager is incompetent about how to go about achieving that quality, or the manager is incompetent.
Also, just parse the requirements, she's asking for confidence that it won't break any features, not that the commit won't actually break any features.
Just be more confident.
Seriously though, find a new job.
I wrote a blog post about clients like this a while back - http://justinvincent.com/page/302/bugs-vs-mistakes-warranted... - I've found that educating the client about QA helps in these situations.
Well, 100% isn't reachable. But a high confidence is reachable. The thing though is, your PM isn't asking you for 100% confidence. He's asking you to make every single 2 hour tasks into a weeklong research and engineering project.
So sure, tell him everytime he asks this, it'll take you a week to make sure.
So sure, tell him everytime he asks this, it'll take you a week to make sure.
It's on jobs like this where you charge by the hour...
maybe you should ask him what exactly he means with "confidence" ?
In the end, you should be able to get a bet on it. If it fixes the problem, without unwanted side effects, you get X. If it doesn't, you pay Y. See if you can work out X and Y.
If he really insists on 100%, and wants to pay for it, you might get rich in the process.
In the end, you should be able to get a bet on it. If it fixes the problem, without unwanted side effects, you get X. If it doesn't, you pay Y. See if you can work out X and Y.
If he really insists on 100%, and wants to pay for it, you might get rich in the process.
When I hear from a manager that I must be absolutely certain that some complex system utterly beyond my control must work without the possibility of error, I leave. (I have done this.) Life is too short to spend it working with manipulative turds, let alone smug imbeciles with no comprehension of computational complexity, recusive unsolvability, probability, the problem of knowledge, the philosophy of science, and on and on. I hate to sound so negative, but surrounding yourself with individuals capable of this kind of psychological torture when the subject of software guarantees is a research industry with an extensive literature going back at least to the Mythical Man Month is bad for your health. I find it deeply offensive that one has to respond respectfully and professionally to outrageous demands as if they were reasonable.
This is an unbelievably stupid request.
Nobody writes bug-free code - people in the comments on SE talking about how this can be done with automated testing are utterly delusional. All developers, no matter how talented and/or cautious, create bugs from time to time.
So if you are to say you have 100% confidence in your code, you are either:
1) The first developer ever to write all bug-free code, all the time (hint: you aren't)
2) Willingly overlooking the fact that no matter how hard you try or how confident you are in your code, you will introduce bugs every so often.
Neither of those is an even remotely reasonable stance to take. This project manager is a total moron.
Nobody writes bug-free code - people in the comments on SE talking about how this can be done with automated testing are utterly delusional. All developers, no matter how talented and/or cautious, create bugs from time to time.
So if you are to say you have 100% confidence in your code, you are either:
1) The first developer ever to write all bug-free code, all the time (hint: you aren't)
2) Willingly overlooking the fact that no matter how hard you try or how confident you are in your code, you will introduce bugs every so often.
Neither of those is an even remotely reasonable stance to take. This project manager is a total moron.
[deleted]
If you must continue to work with this person then you need to play by their rules. Create a manual test suite that takes about 2 hours to complete. Every time a new issue is found tell the manager that you'll add X tests and increase your test suite. Eventually you'll have a test suite that takes longer to run than the bug fixes. If the manager doesn't like the drop in performance ask them which tests you should pull out.
Unit tests are arbitrary magic to non-developers whereas tests written down on paper are tangible. They can see the document grow in size and they'll start to see their name appear on the document (Added 25 more tests by direction of Joe Manager). Managers can hide from unit tests, they can accuse you of not writing enough unit tests, it's harder for them to hide from physical tests.
It's not fun. Really I'd say find a new job.