Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We know the optimal situation of negotiating corrections of specifications with the customer, getting the specs to do what the client wanted, not what they said or thought they wanted. That's negotiating, explaining.

Sometimes, we're unable to convince the client. We're forced to produce broken as designed. This, called "demonology" by merit of mages summoning demons and demons fulfilling their wishes very literally, causing the mage's demise as result, is another approach that will leave the customer very dissatisfied once they realize their error, and of course try to pin the blame on the developer.

Now I just faced a very different approach: the customer created simple specs that fail to account for some critical caveat, and is completely unwilling to fix them, admit the obvious errors and accept suggested corrections. The product made to these specs will be critically broken, and possibly might cost human lives. Still, it's too late to drop the contract entirely. The contract has punitive clauses for that, ones we can't really accept.

The boss' decision? We do the work right and lie to the customer that we did it according to the specs. The algorithms in question are hidden deep enough under the surface, the product will do the work just fine, won't fail in the caveat situation, and unless someone digs too deep, they will never discover we didn't break it as requested.

Is there some common name for this tactics of execution of specs?

share|improve this question

closed as off-topic by gnat, Robert Harvey, user16764, MichaelT, World Engineer Oct 30 '13 at 20:54

  • This question does not appear to be about software development within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Failure to take into account critical scenarios in which lives are endangered is not really a matter for a contract, it's conspiracy to murder. Your company has strong enough morals to do what's right regardless of what the client wants, but will the next one? I think doing it right in this case may involve some sort of whistleblowing. – Phoshi Oct 30 '13 at 10:20
Common sense? Having a conscience? Sounds a bit far-fetched, to be honest. Escalation to a higher level (be that the client's boss, or their investors, or, if all else fails, the courts) should have been the way to go. Refusal to put lives at risk is never wrong. – Amos M. Carpenter Oct 30 '13 at 10:21
This is called "Engineering". When you go to get licensed as a Professional Engineer you have to take an ethics exam, and it deals with situations like this. An Engineer has a responsibility both to protect the public safety, and to act in a professional manner towards their clients. – Scott Whitlock Oct 30 '13 at 10:28
This question appears to be off-topic because it is a "name that thing" question. "Name that thing" are bad questions for the same reasons that "identify this obscure TV show, film or book by its characters or story" are bad questions: you can't Google them, they aren't practical in any way, they don't help anyone else, and allowing them opens the door for the asking of other types of marginal questions. See – gnat Oct 30 '13 at 15:32
@gnat: Excellent. I'll have to put that in my pro-forma comments script. – Robert Harvey Oct 30 '13 at 16:02

Is the requirement(s) in question a flawed, missing or derived requirement? It matters. If the requirement is missing or can be derived from another requirement then it is a simple matter to say it is a derived requirement and you are meeting the terms of the contract. And there is no reason to hide it.

If the requirement contradicts a requirement then how are you going to validate the system without a change in requirements? The most likely reason for the government to not want to change requirements is "you will charge them more". If you are already going to implement with no extra cost then there is little reason for them to object.

Finally, because this is a government job, there will be a paper trail for all these types of decisions, if you want one. If those government employees responsible for your project won't agree verbally to the requirements change then you can formally file a requirements variance. I'm sure any variance request using terms such as "endangering life" will have ZERO possibility of being rejected. In any event, there is no reason to "hide" that you aren't meeting requirements as that could actually result in punitive damages to your company, even though you are trying to do the right thing. In this case, the right thing is to formally escalate the issue and make sure your company is protected. It is not to hide what your are doing from the customer because that is also wrong, although not as wrong as delivering a known safety hazard.

share|improve this answer
Let me emphasize: This is NOT the USA. And these government organizations may not be technical experts but are great at politics. Seriously, if you point out two different dates and ask which one is right, they can reply with a straight face these are both the same date and your request is invalid. Argue with that. – SF. Oct 30 '13 at 18:36
Ah, not the USA. In that case, maybe the government's intent is to create a safety hazard as they have nefarious plans in mind. Thus, by your not adhering to the contract then you are delivering something of no value to them. I hope nobody comes barging through your door some night once they've discovered what you've done behind their backs. – Dunk Oct 30 '13 at 22:10

I am not a lawyer. You should neither act nor refrain from acting on any opinions I provide.

Releasing a product that could put lives at risk due to a design flaw (rather than as a necessary part of its operation) that you are aware of is likely to put you the wrong side of health and safety legislation as well as expose your organisation to legal claims and costs. In most territories and situations the law of the land overrules any contract you may have so that should be your priority.

In other words: Clarify your specific legal position before continuing.

share|improve this answer
SF an analogy would be a seat belt - it doesn't "cause deaths" by itself. However if it fails and the person dies as a result - you can bet the maker is liable and will be sued! The fact that seat belts didn't used to exist on cars doesn't help make a case. – Michael Durrant Oct 30 '13 at 12:01
@SF: If your company is aware of the design flaw, then the company can be held liable. In my company our legal department would never let us sign a contract, which would put the company at risk. If your or your boss lied to your legal department, good luck. – Simon Oct 30 '13 at 12:01
@SF. Seatbelts were not always mandatory. A safety system must work if it's installed. If it fails then the designer/maker is at fault and will be held liable in court. If the cause is found to be a design defect that was known then you can expect the court to show you no mercy. A good lawyer will be able to explain better using appropriate examples. – James Snell Oct 30 '13 at 13:35
I highly suggest to get some professional legal advice. – Simon Oct 30 '13 at 15:09
@SF Look. You don't try to save money by talking to us instead of a lawyer, and then ignore our advice when it's (inevitably) "Talk to a lawyer and not us." – user16764 Oct 30 '13 at 22:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.