Debates

[130 home]

Debate overview

Each student will participate in a classroom debate on a topic related to that day's lecture. The debate topic will be specified by the instructor in advance. Debate teams consist of three (or occasionally two) students. Teams will be assigned by the instructor and teaching assistants. Just before each debate, a coin flip will decide which team gets the affirmative (pro) side of the topic; the other team gets the negative (con) side. The debate then proceeds as follows:

1. (3 minutes). Team A presents the affirmative position, as follows:
   • Introduce the argument.
   • Submit evidence to support the argument.
2. (3 minutes). Team B presents the negative position, as follows:
   • Use the same format as (1) by introducing the negative argument with supporting evidence.
   • Do not directly respond to Team A.
3. (3 minutes). Team A reintroduces the affirmative position and begins rebuttal.
   • Introduce secondary arguments.
   • Submit more evidence.
   • Rebut the other team's evidence and arguments.
4. (3 minutes). Team B reintroduces the negative position and begins rebuttal. This uses the same format as (3).
5. (3 minutes). Team A rebuts and summarizes.
   • Respond directly to the other team's arguments.
   • Sum up key points of your team's position.
6. (3 minutes). Team B rebuts and summarizes. This uses the same format as (5).

Debate time limits are strictly enforced. Each team will decide jointly the order of speakers. Each team member must speak at least once, and during each three-minute period a single team member will be the only speaker.

Prepare carefully for debates, by collecting arguments and evidence, brainstorming as a team for how to present your team's arguments and refute the other team's, and by doing an ungraded practice debate in discussion. Divide labor during preparation to play to the strengths of your team members. The first debaters of each team should have a well-prepared opening statement, since they will know the topic well in advance (although not which side they'll take). Later debaters – especially the last debater on each time – will have to think on their feet, because they will have to respond to the other team's arguments, assertions, and evidence on short notice. Shaky public speakers are encouraged to take the first position.

There will be time for classroom discussion after each debate; the audience should wait until then to make any comments.

Each team member also submits a five-page individual essay on the debate topic. This essay should outline the student's personal opinion on the topic, in the context of a broader argument supported by the evidence. The essay should cite course readings and any other material consulted by the student during preparation for the debate. The essay should use the USENIX template style mentioned in the class resources for written reports and oral presentations.

During the debate, each member of the audience should record the strong points of the debate and make suggestions for improvement, in the form of commentary for that debate. We will ask for copies of this commentary from a few selected students after each debate, and these copies will be graded.

Each debate essay is due on CCLE two days before the debate. Each debate commentary is due on CCLE two days after the debate.

Debate topics

• 04-22 component-level design
  1. Developers should strongly prefer inheritance to delegation.
  2. Multiple inheritance, mixins and traits are more cost-effective than just single inheritance and interfaces.
• 04-24 quality and change management
  1. To improve software quality, pair programming is more cost-effective than formal inspection.
  2. Every file or similar component in a software project should contain a version string that is updated when the component changes.
• 04-29 testing
  1. To improve program structure and quality, test-driven development is more cost-effective than code-driven development.
  2. Software testing and software development should be separate career paths.
• 05-08 project management
  1. A project team in this course should have a single technical leader who manages the project.
  2. For risk management of an enterprise application like my.ucla.edu, agile development is typically more cost-effective in the long term than plan-driven development is.
• 05-13 project planning
  1. Experienced-based cost modeling is typically a better choice than algorithmic cost modeling when developing factory-floor software applications for a high-tech manufacturing firm like SpaceX.
  2. COCOMO II would have been a good choice for modeling the costs for the HPC software developed for the Event Horizon Telescope.
• 05-15 dependability and security
  1. White-box testing is typically more cost-effective than black-box testing for testing the security of applications like my.ucla.edu.
  2. For software reliability in an application like onboard communication and life-support software for the Deep Space Transport, N-version programming is overall more cost-effective than spending the same amount of money improving the reliability of a 1-version program.
• 05-29 tools and formal methods
  1. Formal methods are typically practical only for safety-critical applications, or for applications with an enormous number of users.
  2. Project-specific programming tools are most likely more trouble than they're worth for this quarter's class projects.
• 06-03 user interface and documentation
  1. A native application is typically more trouble to design and maintain than an equivalent web application.
  2. A good software product should need little or no product documentation.

Later topics are to be determined.

Reference

• Beqiri G. Complete guide to debating: how to improve your debating skills. 2018. VirtualSpeech.