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?
15
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.
2
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.
11