Others don't want to lift a finger to protect the data. The next team can add special encryption later if it's necessary, the developers might say. Or they might argue that there's nothing sensitive about it. Teams that ignore these responsibilities are usually able to generate plenty of other code and create piles of wonderful features that people crave. Who cares if they're secure?
There's no simple answer to how much protection to apply. There are only guesses. More is always better -- until the data is lost or the product doesn't ship.
Ethical dilemma No. 5: To bug-fix or not to bug-fix?
It's hard enough to negotiate the ethical shoals when they involve active decisions, but it's even harder when the problem can be pushed aside and labeled a bug that will be fixed eventually. How hard should we work to fix the problems that somehow slipped into running code? Do we drop everything? How do we decide whether a bug is serious enough to be fixed?
Isaac Asimov confronted this issue long ago when he wrote his laws of robotics and inserted one that forbid a robot from doing nothing if a human would be harmed through the robot's inaction. Of course his robots had positronic brains that could see all the facets of a problem instantly and solve them. The questions for developers are so complicated that many bugs go ignored and unfixed because no one wants to even think about them.
Can a company prioritize the list fairly? Are some customers more important than others? Can a programmer play favorites by choosing one bug over another? This is even more difficult to contemplate when you realize that it's hard to anticipate how much harm will come from any given bug.
Ethical dilemma No. 6: How much to code -- or compromise -- to prevent misuse
The original Apple Web camera came with a clever mechanical extra, a physical shutter that blocked the lens when it was off. The shutter and the switch were linked together; there was no way to use the camera without opening the shutter yourself.
Some of the newer webcams come with an LED that's supposed to be illuminated when the camera is activated. It usually works, but anyone who has programmed a computer knows there may be a place in the code where the camera and the LED can be decoupled. If that can be found, the camera can be turned into a spying device.
The challenge for the engineer is anticipating misuse and designing to prevent it. The Apple shutter is one of the obvious and effective examples of how it can be done elegantly. When I was working on a book about cheating on the SAT, I met one hacker who was adding networking software to his calculator. After some deliberation, he decided to only support wired protocols because he was afraid kids would sneak a calculator with Wi-Fi into an exam. By supporting only wired protocols, he ensured that anyone in a test would need to run a wire to their neighbor's machine. He hated skipping the wireless protocols, but he felt the risk of abuse was too high.
Ethical dilemma No. 7: How far to defend customers against data requests
If you collect data, it's a safe bet that your organization will someday be caught between serving your customers and serving the government. Requests to deliver data to legal entities are becoming increasingly common, leaving more and more software and services organizations to contemplate to what extent they will betray their customers' privacy before the law. You can scrutinize these requests and even hire your own lawyers to contest whether they are truly lawful, but the reality is that the courts will be debating legalities long after your funding runs out.