3.2 - Impact of Program Design

System reliability means a program does what it’s supposed to do, under stated conditions, without failing. As a programmer, you should test your program under a variety of conditions to maximize this reliability.

Testing with a variety of conditions means trying more than just the obvious input:

Typical values: the normal inputs the program will see most of the time.

Boundary values (edge cases): values right at the edge of what’s allowed, like 0, the smallest or largest allowed value, or an empty string. A lot of bugs, like writing < where you meant <=, only show up here.

Invalid values: inputs that shouldn’t happen, like a negative age, to check that the program handles them without crashing or giving a wrong answer.

For example, this method is supposed to accept any rating from 1 to 10, inclusive:


// Supposed to return true for any rating from 1 to 10, inclusive
public boolean isValidRating(int rating) {
    return rating > 1 && rating < 10; // bug: should be rating >= 1 && rating <= 10
}

isValidRating(5);  // true, looks fine
isValidRating(-3); // false, correct
isValidRating(1);  // false, but 1 should be valid
isValidRating(10); // false, but 10 should be valid

Testing only 5 would make the method look fine. Testing the boundary values 1 and 10 is what catches the bug.

Programs affect society, the economy, and culture, and that impact can be good or bad. Even a program built to solve one specific problem can end up causing unintended harm outside of what it was meant for.

A few examples, one for each area:

Society: navigation apps help drivers avoid traffic jams, but by rerouting drivers around jams, they have sent heavy traffic onto quiet neighborhood streets that weren’t built for it. Nobody designed the app to do that, it’s an unintended harmful effect.

Economy: software that automates work, like self-checkout or online banking, saves businesses time and money and creates new tech jobs, but it can also replace jobs people used to do.

Culture: streaming and social media apps make it easy to share music, videos, and ideas around the world, but their recommendation algorithms can also spread false information quickly or keep showing people only what they already agree with.

So when you design a program, think about who could be affected by it, not just whether it solves the problem it was built for.

There are also legal and intellectual property issues to think about. Programmers reuse open source code all the time since it’s published and free to use. But if code isn’t open source, you need permission (and often have to pay) before you can legally use it in your own program.

Code is intellectual property: it legally belongs to whoever wrote it (or the company they wrote it for). In the US, code is protected by copyright as soon as it’s written, even without a copyright notice.

Open source code: published so anyone can use, study, and change it for free. It still comes with a license, and most open source licenses have conditions, like keeping the original author’s name and license notice in your copy.

Code that isn’t open source: you need permission from the owner, usually by buying a license, before you put it in your program. Copying it without permission can break copyright law.

Either way, it’s good practice to credit code you didn’t write yourself.

Back Next