Aim for FiveComputer Science A

Unit 3 · Topic 3.2

3.2 Impact of Program Design

Code doesn't just run on a computer; it affects people. This topic covers system reliability and why testing matters, the good and harmful effects programs can have on society, and the legal side of reusing other people's code.

Key terms

  • system reliability
  • unintended consequences
  • intellectual property
  • open source
  • licensing

System reliability

A reliable system does what it's supposed to do, under the conditions it was designed for, without failing. Programmers make systems more reliable by testing them with many different inputs: ordinary values, edge cases like 0 or an empty string, values right at a boundary, and unusual inputs a user might try.

Testing only the easy, typical cases is how bugs slip through. A method that works for an age of 30 might still be wrong for an age of exactly 65.

A good habit is to write down, before you test, what the correct answer should be for each input. Then compare the program's output with your list. A test is only useful if you know what result to expect. Reliability matters most when people depend on a program, like software that schedules medicine doses or controls traffic lights, because a failure there hurts real people.

Impacts on society, the economy and culture

Programs change how people live, work and communicate. Many effects are good: apps that help people find medical care, software that lets small businesses sell online, tools that make information available to anyone.

Programs can also cause harm, including harm nobody intended. A navigation app that sends drivers down quiet side streets to save time can flood a neighborhood with traffic. A social app designed to connect friends can be used to spread false information. A program that automates a task can save money for a business and also eliminate jobs. Good programmers think about who could be affected, not just whether the code works.

Intellectual property and licensing

Code is intellectual property: creative work that legally belongs to whoever wrote it, or to the company they wrote it for. Programmers reuse code all the time, but they have to follow the rules for it.

  • Open-source code is published so others can use it for free, under the terms of its license. Some licenses just ask you to credit the authors; others have more conditions.
  • Code that isn't open source needs permission from its owner before you put it in your program, and often you have to pay for it.
  • Finding code online doesn't make it free to use. Check the license first, and keep any credit or license notice the license asks you to include.

Worked examples

Try each one yourself first, then open the solution.

  1. Example 1

    Choosing tests that find a bug

    A theater charges 8 dollars for children under 12, 9 dollars for seniors 65 and older, and 14 dollars for everyone else. A programmer tests this method with ages 30, 5 and 70, and gets 14, 8 and 9, so they decide it works. Is it reliable? What tests should they add?public static int ticketPrice(int age) { if (age < 12) { return 8; } else if (age > 65) { return 9; } return 14; }

    Show the solution
    1. Step 1: The three tests are all typical values in the middle of each group, and they all pass.
    2. Step 2: Boundary values are where bugs hide, so test the exact cutoffs: 12 (the first age that isn't a child) and 65 (the first senior age).
    3. Step 3: ticketPrice(12) returns 14, which is correct.
    4. Step 4: ticketPrice(65) checks 65 > 65, which is false, so it returns 14. A 65-year-old should pay 9. The condition should be age >= 65.

    Answer: It isn't reliable: a 65-year-old is charged 14 instead of 9. Testing the boundary ages 12 and 65 (and maybe 11 and 64) finds the bug; the fix is age >= 65.

  2. Example 2

    Explaining an unintended consequence

    A city releases an app that lets residents report potholes with a photo, and the road crew fixes the most-reported ones first. Describe one benefit and one possible unintended harmful effect.

    Show the solution
    1. Step 1: Benefit: residents can report problems quickly, and the city gets more information than before, so roads get fixed faster.
    2. Step 2: Look for groups who use the app less. Neighborhoods where fewer people own smartphones, or where people work long hours, may send fewer reports.
    3. Step 3: Because repairs follow report counts, those neighborhoods could get repairs later, even if their roads are worse. The program would create an unfair result that nobody intended.

    Answer: Benefit: faster reporting and repairs. Unintended harm: areas with fewer app users get fewer reports, so their roads may be fixed last even when they need it most.

Common mistakes

  • Testing only typical values. Always test boundaries and edge cases too.
  • Assuming code you found online is free to use. Check whether it's open source and what its license requires.
  • Describing only the intended effect of a program when a question asks about unintended consequences.

On the exam

  • Multiple-choice questions may ask which set of test cases best checks a method, or which statement about open-source code is true. Choose the tests that include boundary values.

Connected topics

Videos

Check yourself

4 questions on 3.2 Impact of Program Design. Pick an answer to see if you got it, and why.

Question 1 of 4

A team has written a program that calculates shipping costs. Which of the following actions would do the most to improve the program's reliability?

Question 2 of 4

A navigation app sends drivers along the fastest route. After it becomes popular, quiet residential streets near a highway fill with traffic whenever the highway is slow. Which of the following best describes this situation?

Question 3 of 4

A developer finds code in a commercial product that would save her weeks of work. The code is not published as open source. What should she do before including it in her own program?

Question 4 of 4

Which of the following best describes code that is published as open source?

0 of 4 answered