[OT] technical arguments (humor)
chrisn at Kronos.com
Wed Jan 17 15:50:33 UTC 2001
I apologize in advance for sending non-Squeak stuff to the list, but... I'm
guessing that many of you can use them. :-)
> From http://pigdog.org/auto/mr_bads_list/shortcolumn/1914.html:
> Things to Say When You're Losing a Technical Argument
> 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
> 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
> 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
> 27. No, that would break object encapsulation.
> 28. I don't think that's altogether clear. Please write it up in UML for
> 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
> 40. This one is in the FAQ:
> 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?
More information about the Squeak-dev