Impact of Program Design

So far, every program in this course has lived on your own screen. If it printed the wrong thing, you were the only one who saw it. Real programs are different. Once a program is released, thousands of people may depend on it to get to school, buy food, do their jobs, or talk to friends. Whatever the program does, good or bad, it does to all of them.

Programmers therefore have to think about more than “does it compile?” They also have to ask “what will this do to the people who use it, and to the people around them?” An impact of a program is any effect it has on people beyond the screen. It helps to sort impacts into three areas:

The key point is that impacts come in two kinds. A beneficial impact makes things better for someone; a harmful impact makes things worse. One program usually has both, often for different groups of people. That is why “is this program good?” rarely has a one-word answer.

Now change one thing: the group you look at. For a student with a phone, LunchLine is almost all benefit. For a cashier, it may be mostly harm. For a student without a phone, it can turn lunch from equal for everyone into slower for some. The program did not change; the person did. Impact always depends on whose point of view you take, so a careful programmer asks the question from several points of view.

Some harms are easy to predict before a program is released. Others surprise everyone, including the people who wrote the program, because they come from people using it in ways its designers never pictured.

Every program is written to fill a need or solve a problem. That goal is its intended use. But once a program is in the world, people use it however they like, and the program does exactly what its code says no matter who is using it or why. An unintended effect is a result the designers did not plan or expect. When it hurts someone, it is an unintended harmful effect, and it can happen even when everyone who built the program had good intentions.

Think of a kitchen knife. It is designed to cut food, and almost everyone uses it that way. The designer never meant for it to be used to hurt anyone, yet a knife can still cause harm. Programs are similar, with one difference that makes them riskier: a program can reach millions of people at once, so a small unintended effect can grow very large very fast.

Now vary one thing: the person using the program. A hypothetical app that shows the live location of a delivery driver is intended to tell customers when food will arrive. Used by a customer, it does just that. But the same feature, in the hands of someone who wants to follow the driver, could put the driver at risk. Here the unintended harm comes not from many users but from one user with a different goal. Asking “how could someone misuse this?” is part of designing a program responsibly.

Some harm happens simply because a program does not work. If a bus-tracking app says the bus is ten minutes away when it is actually at the stop, a student misses school. People can only depend on a program that does its job every time they need it.

Recall from Topic 1.1 that a logic error gives a wrong result and a run-time error stops a program early. One error found by one tester is a small problem. The same error in a program that thousands of people depend on is a big one.

System reliability means a program can do the tasks it is supposed to do, as expected, under its stated conditions, without failing. The stated conditions are the situations the program is promised to handle: the kinds of input, the number of users, the devices it runs on, and so on. A reliable program does not have to do everything. It has to do what it promised, in every situation it promised to cover, every time.

int totalPoints = 45;
int gamesPlayed = 3;
System.out.println("Season report");
int pointsPerGame = totalPoints / gamesPlayed;
System.out.println("Points per game: " + pointsPerGame);

Season report
Points per game: 15

int totalPoints = 0;
int gamesPlayed = 0;
System.out.println("Season report");
int pointsPerGame = totalPoints / gamesPlayed;
System.out.println("Points per game: " + pointsPerGame);

Season report
Exception in thread "main" java.lang.ArithmeticException: / by zero

int totalPoints = 0;
int gamesPlayed = 0;
System.out.println("Season report");
if (gamesPlayed > 0)
{
    int pointsPerGame = totalPoints / gamesPlayed;
    System.out.println("Points per game: " + pointsPerGame);
}
else
{
    System.out.println("No games played yet");
}

Season report
No games played yet

Stated conditions work in both directions. If this app’s description had said “for players who have played at least one game,” a player with zero games would be outside the stated conditions. Even then, a careful programmer would handle it, because real users rarely read the fine print. Clear stated conditions tell everyone what the program must do; reliability is meeting that promise.

int totalPoints = 7;
int gamesPlayed = 2;
System.out.println("Season report");
if (gamesPlayed > 0)
{
    int pointsPerGame = totalPoints / gamesPlayed;
    System.out.println("Points per game: " + pointsPerGame);
}
else
{
    System.out.println("No games played yet");
}

Season report
Points per game: 3

Sooner or later, a program’s users will run into situations its programmer never tried. Programmers want to find the failures first, and their main tool is testing on purpose with many different conditions before the program is released.

Recall that testing means running a program with specific data and comparing the actual result to the expected outcome. The question now is which data to choose. Picking several values that are all alike (“8, 9, 10”) tells you almost nothing new after the first one. Good test data is chosen to cover different situations:

Boundary cases matter because, as you saw in Unit 2, < versus <= changes the result only at the boundary. A program with that mistake passes every typical test and fails only when the value lands exactly on the line.

import java.util.Scanner;

public class TicketPriceTests
{
    public static void main(String[] args)
    {
        Scanner testAges = new Scanner("8 30 70 12");
        for (int test = 1; test <= 4; test++)
        {
            int age = testAges.nextInt();
            int price;
            if (age < 12)
            {
                price = 6;
            }
            else if (age < 65)
            {
                price = 10;
            }
            else
            {
                price = 7;
            }
            System.out.println("Age " + age + ": $" + price);
        }
    }
}

Age 8: $6
Age 30: $10
Age 70: $7
Age 12: $10

Now vary the condition on line 12 to age <= 12, and add more boundary tests on both sides of both rule changes:

import java.util.Scanner;

public class TicketPriceFixed
{
    public static void main(String[] args)
    {
        Scanner testAges = new Scanner("8 30 70 12 13 64 65");
        for (int test = 1; test <= 7; test++)
        {
            int age = testAges.nextInt();
            int price;
            if (age <= 12)
            {
                price = 6;
            }
            else if (age < 65)
            {
                price = 10;
            }
            else
            {
                price = 7;
            }
            System.out.println("Age " + age + ": $" + price);
        }
    }
}

Age 8: $6
Age 30: $10
Age 70: $7
Age 12: $6
Age 13: $10
Age 64: $10
Age 65: $7

Every result now matches the price table. The tests at 64 and 65 show that the second rule, age < 65, was already correct. Testing both sides of each boundary is how you know a rule changes in exactly the right place, not one value early or late.

import java.util.Scanner;

public class ShippingTests
{
    public static void main(String[] args)
    {
        Scanner testOrders = new Scanner("20 80 50");
        for (int test = 1; test <= 3; test++)
        {
            int orderTotal = testOrders.nextInt();
            if (orderTotal > 50)
            {
                System.out.println(orderTotal + ": free shipping");
            }
            else
            {
                System.out.println(orderTotal + ": shipping costs $5");
            }
        }
    }
}

20: shipping costs $5
80: free shipping
50: shipping costs $5

if (orderTotal >= 50)

20: shipping costs $5
80: free shipping
50: free shipping

Creating a program raises questions not only about what it does to its users, but about the code itself: who owns it, and who is allowed to copy it?

Writing a program takes real work and creativity, just like writing a song or a novel. The law treats it the same way. Intellectual property is something a person creates with their mind, such as a song, a drawing, a story, an invention, or a program. The creator, or the company they made it for, has legal rights over it, including the right to decide who may copy it, use it, or sell it.

That means programmers face legal issues whenever they use code they did not write. Code you can see on a website is not automatically free to take, any more than a song you can hear online is free to put in your own album. Copying someone else’s code into your program without permission can break the law, even if you change a few names.

Now vary one detail of the second row: suppose the company’s website says “you may use this code in your own programs.” The code is identical, and so is the owner, but now Maya has permission, so the legal concern is gone. What makes code safe to reuse is not where you found it but what its owner allows.

In Topic 3.1 you saw that reusing code, instead of writing the same thing again, helps manage complexity. Professional programmers reuse code written by other people all the time, yet that code is someone else’s intellectual property. So how do they reuse it legally?

There are two main routes, and which one applies depends on how the code’s owner published it.

Open source code is code whose owner has published it so that anyone may use it for free. Programmers can put open-source code into their own programs without asking first. Open-source code comes with a license, a short statement of what users may do and any simple conditions to follow, such as keeping the original author’s name in the code. Following the license is part of using the code legally.

Code that is not published as open source belongs to its owner in the ordinary way. To put it into your program, you must get permission from the owner, and often you must purchase the right to use it before you include it.

Now vary the team’s choice: suppose they skip both steps and copy a chart function out of the company’s package because a classmate shared the file. The code works just as well, but the team used intellectual property without permission. If the app is released, the company could take legal action. Getting the feature is never the whole question; getting it the right way is part of the job.

A hypothetical student, Dev, builds a parking app for a busy school. Students check how many parking spots are open in each lot before they leave home. Follow Dev through every idea in this chapter.

Reusing code (3.2.5, 3.2.6). Dev needs a map to show the lots. He finds an open-source map library whose license asks users to keep the authors’ names, and a fancier map package sold by a hypothetical company. He picks the open-source library and keeps the authors’ names in his code, as its license asks. Had he chosen the company’s package, he would have needed the company’s permission and probably a purchase first.

Reliability and testing (3.2.3, 3.2.4). Dev’s description states that the app shows the open spots in each lot, which hold up to 50 cars. He writes down his stated conditions, then chooses test cases on purpose:

His first version still shows an open spot when exactly 50 cars are parked, because one comparison used <= where it needed <. Only the boundary test exposes this logic error. He fixes it before anyone relies on the app to decide where to park.

Impacts (3.2.1). Socially, students spend less time circling the lots, and fewer late arrivals mean fewer missed first periods. Economically, the school may need fewer staff directing traffic. Culturally, the morning routine changes: students leave home based on an app instead of habit.

Unintended harm (3.2.2). After launch, students who see “Lot A: 2 spots” all race to Lot A at once, making the driveway more dangerous than before. Dev never intended that. He responds by showing ranges (“a few spots”) instead of exact counts, and by testing what happens when many users get the same information at once.

Every part of this story involves a choice about how the program is designed: which code to reuse, which tests to run, and how the information is shown. Those design choices are what decide the program’s impact.

• Creating a program has impacts on society, the economy, and culture, and the same program can be beneficial for some people and harmful for others.
• A program written to fill a need can cause unintended harmful effects beyond its intended use, even when its designers meant well.
• System reliability means a program performs its tasks as expected under its stated conditions without failure.
• Programmers maximize reliability by testing with a variety of conditions, especially boundary and special cases that typical values miss.
• Code is intellectual property. Open-source code may be reused for free by following its license; other code requires the owner’s permission and often a purchase.

for (int temperature = 66; temperature <= 69; temperature++)
{
    if (temperature < 68)
    {
        System.out.println(temperature + ": heat on");
    }
    else
    {
        System.out.println(temperature + ": heat off");
    }
}

66: heat on
67: heat on
68: heat off
69: heat off

Check each statement. If the answer is “not yet,” reread the linked subsection.

• I can describe beneficial and harmful impacts of a program on society, the economy, and culture. Reread
• I can explain how a program can cause harm beyond its intended use. Reread
• I can define system reliability and explain what stated conditions are. Reread
• I can choose typical, boundary, and special test cases for a program. Reread
• I can explain why using someone else’s code raises legal and intellectual property issues. Reread
• I can tell when code may be reused freely and when permission or purchase is needed. Reread