Things to say when you are losing...
70 things to say when you are losing a technical argument. I believe I've heard most of them at one point or another - well, except #8 - I've never heard of that guy before.
My favorites:
- #1: That won't scale. I hear that one all of the time. It is easy to win back the argument though - just say "Why?".
- #6: That can't be generalized to a cross-platform build. But the way I hear it is "that would not be database independent..."
- #11: Yes, well, that's just not the way things work in the real world. Ugh, I hate that one. What they really mean is "hey, our standard operating procedures - drafted in the year 1985 - don't permit intelligent decisions".
- #12: I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting? You only fall for that trap once or twice :)
- #20: Have you LOOKED at the number of I/O requests that will create? Always respond with - so I presume you have, save us the time - how many are we talking about and why?
- #25: No, no, no. We're really working on an N-TIER architecture here. No comment
- #48: Let's table this for now, and we'll talk about it one-on-one off-line. Now you know what they really mean....
posted by Thomas Kyte at 12:25 PM
14 Comments:
Good one...
here we generally call such things "managers' talks" ;)discussing every aspect, almost without knowing anything about how does it happen....
dont know really about managers outside india...but here the story is like this only (obvsly there are some xceptions)....
Sidhu
Yes - our managers have heard of things like scalability, but not one of them has any technical ability to back anything up - ever!
Does anybody else work where it's an absolute no-no to have tecnical knowledge in a management postion?
See #3.
Heard at a preliminary design review: "I agree that it works in practice, but does it work in _theory_?"
does it work in theory
Loved that one :)
good!
"I agree that it works in practice, but does it work in _theory_?"
awesome :)
Sidhu
Here's one:
"I already have a C++ wrapper class that does the same thing."
Brilliant!
Arun: Reference Paula at http://worsethanfailure.com/Comments/The_Brillant_Paula_Bean.aspx
Wrapper, yeah, seen that one before...
1. That is not the way we do things here.
2. This is not part of the process.
3. If we did it this way in the past, why do we want to do it your way in the future. (My response is just because you were did something stupid in the past, is not a good reason to do something stupid in the future).
4. We did that once. It didn't work.
Here is one...
"It does not match our enterprise standards." - said the client while commenting on the use of a programming language.
PERL was picked over JAVA.
It's funny because they use 10g ,PS and the latest one oracle bought. JAVA is not part of the enterprise standard there.
"That's a really good idea. We should probably do it that way. But we do not have enough time in this project. We'll do it that way next time." -- when told about referential integrity, check constraints, API packages, security, and ...
[referring to views and/or procedures]
"No, your solution is not database independent."
[later on...]
"He wants to query the db from Python? Ok have him convert all these functions to Python."
[later on...]
"She wants to query the db from VB? Ok have her convert all these functions to VB."
Very interesting!
POST A COMMENT
<< Home