[OT] technical arguments (humor)

Norton, Chris 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.  :-)

---==> Chris

> 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
> 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? 





More information about the Squeak-dev mailing list