Box 10.2 Reasons for Not Accepting the Results of an Analysis
- 1. This needs more analysis.
- 2. You need a better understanding of the workload.
- 3. It improves performance only for long I/Os, packets, jobs, and files, and most of the I/Os, packets, jobs, and files are short.
- 4. It improves performance only for short I/Os, packets, jobs, and files, but who cares for the performance of short I/Os, packets, jobs, and files; its the long ones that impact the system.
- 5. It needs too much memory/CPU/bandwidth and memory/CPU/bandwidth isnt free.
- 6. It only saves us memory/CPU/bandwidth and memory/CPU/bandwidth is cheap.
- 7. There is no point in making the networks (similarly, CPUs/disks/...) faster; our CPUs/disks (any component other than the one being discussed) arent fast enough to use them.
- 8. It improves the performance by a factor of x, but it doesnt really matter at the user level because everything else is so slow.
- 9. It is going to increase the complexity and cost.
- 10. Let us keep it simple stupid (and your idea is not stupid).
- 11. It is not simple. (Simplicity is in the eyes of the beholder.)
- 12. It requires too much state.
- 13. Nobody has ever done that before. (You have a new idea.)
- 14. It is not going to raise the price of our stock by even an eighth. (Nothing ever does, except rumors.)
- 15. This will violate the IEEE, ANSI, CCITT, or ISO standard.
- 16. It may violate some future standard.
- 17. The standard says nothing about this and so it must not be important.
- 18. Our competitors dont do it. If it was a good idea, they would have done it.
- 19. Our competition does it this way and you dont make money by copying others.
- 20. It will introduce randomness into the system and make debugging difficult.
- 21. It is too deterministic; it may lead the system into a cycle.
- 22. Its not interoperable.
- 23. This impacts hardware.
- 24. Thats beyond todays technology.
- 25. It is not self-stabilizing.
- 26. Why changeits working OK.
|