Head in the Clouds: SaaS, PaaS, and Cloud Strategy

Sep 30 2015   9:34AM GMT

Should you ponder the ethics of cloud apps you create?

Joel Shore Joel Shore Profile: Joel Shore


Let’s do some supposin’.

Suppose you work for a giant, global manufacturer. The company might make air conditioners. Or diesel-powered cars. Suppose you’re given detailed specifications for an embedded software project that disguises the operating status of a product being designed. Suppose the purpose of that application is to underreport the electricity consumed by that air conditioner.

Or — and this just might be the wackiest idea ever — suppose the purpose of the software is to surreptitiously shift a car’s diesel engine into a low-pollution “clean” mode while the engine is running and sensors detect that the steering wheel isn’t being moved and the wheels aren’t rotating. That would present artificially low levels of exhaust pollutants and particulates to environmental test equipment. I know, who could ever dream up such an outlandish, ridiculous scheme? It would be scandalous on an international level.

Here’s the tough question: What would you do if tasked with coding such a program?

You might keep your mouth shut, write the code, grin, and deposit your hefty paycheck. You might become a whistleblower and contact the authorities or the media. You might rationalize the situation and conclude you were just following orders. Perhaps your conscience might drive you to quit and find employment elsewhere. You might even write a time bomb into the code that prevents a car from shifting into low-pollution test mode. What would you do?

As a software developer, are you bothered by the premise of building apps designed to deceive? Have you ever been asked to this? Share your opinions, we’d like to hear from you.

4  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • FTClark
    Yes, I have been asked to do unethical things at my work. It happens only infrequently. The longer you are in the workforce the more likely it has happened to you.I carefully considered the details of the ethics involved. Sometimes the ethics  aren't all that clear. Sometimes my responsibility isn't all that clear. Yes! I tried to provide feedback about the ethics. Sometimes I am heard and something is changed. Sometimes it does take a while. Sometimes things don't change. Does this all sound ambiguous? I have a lot of sympathy for those I read about in the news because I know the difficulties and struggle. I am disgusted by those who are quick to pass judgment. There, but for the grace of God, go I.
    1,280 pointsBadges:
  • TheRealRaven
    Define "ethical".

    In the current news case, I'd resign. (I've resigned for less serious reasons.) Whether or not I'd blow a whistle is a different question since it should have been almost obvious that such a scheme would be discovered anyway. Why blow a whistle when the blowup is already on its way?

    But there are less significant cases, too. The real trouble comes in finding the dividing line. I've willingly developed code that was "deceptive" to users, and I had no ethical concerns at all.

    One aspect of some brand new applications is that they may be sparsely populated with data in the beginning or that there may only be a few app functions competing for the app's resources. As time passes and app development matures, files get bigger, menus get longer, more interfaces get used by other apps -- response time can increase accordingly. That can cause a rise in dissatisfaction among users.

    One way to approach that is to build in slight delays at various points in the beginning. As things get slower in the future, those delays can be removed. Response times may still increase, but it becomes easier to manage the expectations of the users. Done well, it can even decrease response times over the app's life-cycle.

    Deceptive? Yes. But ethical...? Other examples are possible.

    Somewhere in between there is a dividing line.
    35,060 pointsBadges:
  • Joel Shore
    I'm with you on response times. Decades ago, in my systems analysis and programming days, it was standard practice to insert time-killer loops in CICS Cobol programs, especially when accessing VSAM files stored on IBM 3370 DASD subsystems. As applications become more heavily used, we could always shorten the time-waster loop to maintain level performance. In a clinical sense, that was deceptive, yet harmless. Creating deceptive code with the intent of skirting laws raises the issue to a new level.
    2,765 pointsBadges:
  • Joel Shore
    For many, it boils down to putting food on the table.
    2,765 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: