file is: debates.txt version 9.0 Elliott, 376/394 Debate Questions. (Be prepared to argue either side.) Debate rules: You will be given about three minutes to prepare to argue one side or the other of each question, so your group will best have discussed these questions (via email?) ahead of time. Each group member must make at least one comment before anyone is allowed to make more than one comment during the debate; if you are shy, go first and make one of the obvious points. Once everyone has spoken once, group members may contribute at will during the group's turn. Two teams will debate at a time. The "floor" will alternate between teams in short intervals, controlled by the clock. A good strategy is to know BOTH sides of each question so you can be prepared not only to carry your own argument, but also prepared to refute the arguments THEY are likely to make. Assuming that the equipment is available, we will likely have the video recorder present. The Questions: -1. A. Requirements are INTENDED to be formal. Groups should construct the requirements, develop tests to assess whether or not the requirments have been met, and rigorously stick to the plan. B. Groups should use requirements as a GUIDE, but not be strictly bound to them -- otherwise creativity suffers, and needless formality limits opportunities. 0. For small projects, such as the maintenance projects, it is not necessary to have a plan, a design, testing, management, and so forth. Just throwing some time and good people at it works more efficiently. 1. As a small group grows larger, it is necessary to spend a higher percentage of time on planning and organization. That is, if a group of five requries 15% of all worker hours on planning a group of nine might require 30% of all worker hours on planning to work at the same level. 2. It is better to have three programmers each making $150K a year working on a project than it is to have nine programmers / administrators each making $50K a year working on the same project. 3. Managers, since they are strictly overhead (don't directly contribute to the product), are thus unnecessary. 3. Designers don't need to know how to write code. 4. To get a project completed all you need is a bunch of people who know how to write code. 5. If you are able to work well by yourself you will be successful working in a group. The problems in working in a group are essentially few and relatively easily overcome if you have good workers. 6. Even though you will lose some time, it is better to build a prototype running system, which is then completely discarded, before building your final system. This way you can get a feel for both the technology, and for how the final version should be designed, thus doing a much better job. This is in contrast with carefully designing, and then implementing, your system right the first time. 7. The idea that excellent communication in a group is necessary is a myth: what really matters is people getting their job done without a lot of focus on talking about it. 8. You have two candidates for a position that is quite critical technically, and at the heart of a somewhat extensive project. One person is very knowledgable, and an outstanding coder, but does not get along with people, is arrogant, and is not communicative. The other person is O.K. technically, but a really a super personality that communicates well, and makes others around her better. In this case you should just face facts and hire the monster coder. 9. The future of wireless is quite limited because after the novelty wears off, and the basic applications are written, we will all find that the medium is just too limited to get much useful work done. 10. "Getting along" in a group is not important, and should not be considered by management. Being professional and getting the job done is all that matters. 11. Possibly other questions, at "run time." I look forward to your arguments!