Things to Say When You're Losing a Technical Argument

by Mr. Bad, Crackmonkey

2001-01-05 16:42:57

Mr. Bad's List

Mr. Bad and Crackmonkey collaborate on a fine Mr. Bad's List. We put together ALL the TECHNOLOGY you ever need to know in order to STUMP your OPPONENT in a technical argument. Use these only when your back is against the wall -- they're definitely desperation tactics.

1. That won't scale.
2. That's been proven to be O(N^2) and we need a solution that's O(NlogN).
3. There are, of course, various export limitations on that technology.
4. The syntax is idiosyncratic.
5. Trying to build a team behind that technology would be a staffing nightmare.
6. That can't be generalized to a cross-platform build.
7. Unfortunately, the license would contaminate our product.
8. If we go with that idea, we're going to have Don Marti camped out in the front lobby with 300 angry software jihad supporters.
9. Our support infrastructure simply can't handle the volume that change would involve.
10. I had one of the interns try that approach for another project, and it scrambled the CEO's hard drive. So I think it's going to be a hard sell.
11. Yes, well, that's just not the way things work in the real world.
12. I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting?
13. Unfortunately, we're an all-FORTH shop. Otherwise, it's a nice idea.
14. I think you need to stop taking this so personally. We need to think about what's best for the project, not about our own little pet theories.
15. Oh, I played with that approach back as an undergrad. Got a D, too.
16. I was reading about that on BugTraq yesterday.
17. Yes, I believe that's the approach Windows NT is taking.
18. That's totally inefficient on modern hardware.
19. Well, yes, but it really reduces to the knapsack problem in that case. Do you have some kind of heuristic, or are we dealing with an NP-complete case?
20. Have you LOOKED at the number of I/O requests that will create?
21. We can't afford the transaction overhead.
22. Yeah, or we could all just plink away on Amigas or something.
23. What? I don't speak your crazy moon-language.
24. Hmm. Didn't they just go bankrupt? It's OK, I guess -- there's some German company who's picked up the existing service contracts.
25. No, no, no. We're really working on an N-TIER architecture, here.
26. No, no, no. It's fairly important that the database be in THIRD NORMAL FORM.
27. No, that would break object encapsulation.
28. I don't think that's altogether clear. Please write it up in UML for me.
29. I think there's a problem with your drive geometry.
30. Can you generate some USE CASES that would justify the change?
31. How is that going to impact the schedule?
32. RAM is cheap and all, but...
33. It would probably be best if we deferred that until version 2.0.
34. I like it, but it is too point-oh for my tastes.
35. If you make this change, I will fork the code.
36. Yes, well, unfortunately the economy is going away from anything remotely like that. Our investors would kill us.
37. Jakob Nielsen wrote an interesting hit piece on that.
38. Yes, yes, we've all read DJB's RFCs on the subject.
39. This is all covered in Knuth, and we don't have time to go over it again.
40. This one is in the FAQ: http://www.linuxmafia.com/~rick/faq/#your_dumb_technology
41. I don't have time for this extropian nonsense.
42. Well, I guess we could start the QA cycles again from square one. That would require a press release, though.
43. You used to program in Pascal, didn't you?
44. Why don't we make a generalized solution including both options, and let the administrator decide with a config-file setting?
45. You've obviously ignored the various namespace issues.
46. I don't think you're considering the performance trade-offs.
47. What kind of benchmarks have you been running?
48. Let's table this for now, and we'll talk about it one-on-one off-line.
49. This really doesn't jibe with our core competency.
50. This sort of thing should really be outsourced.
51. I remember that IBM had a project to do that back in the 70s.
52. Um, hello? We're using VON NEUMANN MACHINES HERE.
53. We need this to fit on a single floppy.
54. Yes, but can this be embedded in a toaster, for example?
55. We need something that my mom can use.
56. Users won't want to click through that many layers of hierarchy.
57. The packaging costs will be prohibitive.
58. OK, but what about internationalization?
59. Look, would you just get off your Be obsession for FIVE MINUTES and talk serious design with us?
60. That's a good idea -- you should do that on your home page.
61. Yeah, Linuxcare tried that with the Sourceror project.
62. Ho, man! Are they still AROUND? That's so cool. I thought that whole idea was discredited years ago.
63. What you're not seeing is the difference between an 'is-a' and a 'has-a' relationship.
64. There is no hope for the widow's son, Boaz.
65. Yes, but we're standardizing on XML.
66. That doesn't fit into the MVC model.
67. Well, that's great if you have an AI running the thing.
68. Well, they're going to do that with the next version of Perl, so we should probably wait.
69. Well, they're going to do that with the next version of OS X, so we should probably wait.
70. I heard that the only real application for that technology was child pornography. How did you hear about it?

tunafish@pigdog.org