- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Stories like this always make me wonder which hurricane-in-human-disguise swept through and made them that scared of anything 'unpredictable.'
Admin
Nothing so spectacular. They just probably had to do with regulators of some sort.
Admin
The correct way to handle such a situation is to mention that an immediate update of the report is a feature required by key users and scoping it, so the business has to decide. The biggest issue is going over the decision makers' heads.
Admin
"If we don't do this we will fail" "Yes. We fail every time. It is 100% predictable"
Admin
A bureaucracy moves at the speed of its dullest most slothful member.
Admin
This was absolutely the end product of financial regulations. Not that you don't want banks to be regulated! But the inevitable result is that financial companies have to tick whatever boxes the regulators insist they tick, and that leads to box-ticking becoming the goal. Tim C. thought his deliverable was a software feature for the customer, but the deliverable the customer needed MORE was all the artifacts they can use to prove to the regulator that this new piece of software was from a known source and properly vetted. As a new module it probably needed a new entry in a database of software, and that means paperwork showing how it was paid for, how it will be supported, how you'll replace it if the vendor is no longer viable, what risk it introduces to the company (inherently, if it breaks, and if it has flaws), who is responsible for managing it... "I whipped this up over the weekend in my hotel room" sounds to a bank IT manager like "I created a guaranteed audit failure for you!"
So the real WTF is not understanding your customer's needs :D
Admin
I do not understand how this is a WTF. I'm not trying to be funny or sarcastic, it's simply the normal way of business. At no point did the phrase "what the fsck" enter my head.
Admin
Given the requirements stated in the article, what the users wanted was Excel. Obviously.
Admin
Precisely.
Admin
Don't become complacent just because regulators are involved. Bernie Maddoff's Ponzi scheme ran for 20 years under the eyes of regulators, whereas the original Charles Ponzi's scheme only made it 8 months without any!
Admin
The WTF is you aren't getting out of this without something stupid happening. New module? They're upset because that wasn't in The Plan. Omit the report? They're upset because the report is in The Plan. Jam the code sideways into an existing module and charge the wrong subproject? Keep doing that and the result will belong on this site.
If you insist on having a giant edifice documenting an activity there are three possibilities. 1) you do a lot of work making the edifice match reality. 2) you accept reality will do nonsensical things to preserve the edifice. 3) you accept that the edifice is a bald-faced lie.
I'm too honest to work for a company with stringent regulations, I guess. There would be a lot of "document X obliges me to tell you Y" or "per the timeline, I am required to claim that task Z is completed". And shouting matches over updating the documents to match reality.
Admin
Working in a bank, that was my initial thought - but on re-reading, it looks like he implemented exactly what the Plan told him to implement, but because he described it as "a new thing" rather than "a bespoke customisation of our existing thing", or just "how our thing will implement your requirements", the whole Plan exploded as though Jadis had spoken the Deplorable Word
Admin
I never expected to see the last Queen of Charn appear in Daily WTF comments!
Admin
In my wife's line of work there were plenty of stupid things. When discussing it with vendors, she'd preface the stupid things with "Our legislation tells us...." meaning, "yes it's stupid, and yes that's exactly what we're going to do because we have to."
Admin
I'm not entirely surprised. Springing something like this on a customer can be bad news, especially in highly regulated industries where everything needs to be predictable and stable. Their design likely already went through multiple iterations on what does what and interfaces to what and the side effects and such were mapped out. Now you add a module all of a sudden and that analysis goes out the window. I mean, sure it does what you want, but can you say it does it safely and predictably? That there are no bugs in it that might do things like alter memory that might change something critical? Someone doing a transaction for $10 a share instead of $100 a share might qualify. Or somehow, they bought one share less or too many than their order specified?
Admin
There is one thing that people who have not worked in a highly regulated field fail to understand. The purpose of certification, regulation and compliance is NOT to keep things from failing, systems from defrauding people, being hacked, killing people or generally going to hell. It's to let the company cover its behind when they inevitably do.
So yes, the whole thing is just one giant box ticking exercise. But those boxes are important. Because when shit inevitably happens and everything goes to court the company can point at its worksheet and say: "See! Look! All the boxes are ticked! We complied with all the standards. We followed all the regulations." and get off scot-free. The court literally has no choice but to say "Well, yea. You followed all our rules. You did all we asked you to do." and let them off. Where as if there is even a single box left open or even a single point of non compliance that the prosecution can point to they would be found to be in the wrong and on the hook for a lot of money.
And this is why companies working in such fields are so extremely procedure obsessed. Because to them a piece of software that does the job right 3 out of 4 times and literally kills people on the 4th but is compliant and ticks all the boxes is literally less of a legal risk than one that works 999999 out of a million times but does not comply.
Because million-to-one chances crop up nine times out of ten. And when that happens, you don't want to be the one holding the liability bag.
Admin
@ Worf:
"I mean, sure it does what you want, but can you say it does it safely and predictably? That there are no bugs in it that might do things like alter memory that might change something critical?"
This "problem" you describe exists for any-and-all new or modified code! If you want a 100% guarantee, you must NEVER allow ANY code change!
Back in the real world, as programmers, we minimize that risk with carefully-thought-out test cases and with code reviews.
Admin
It's not about having 100% guarantee that the code won't fail. It's about having predictability and liability coverage when it inevitably does.
It's about doing your homework and making sure that the risks are understood, written down, deemed acceptable by decision makers and properly mitigated either through testing or procedure.
"This code might cause errors on someone's account balance once in a million transactions and we don't know about." it is far, far more dangerous than "This code might cause the same error once in a thousand transactions but we know about it, have it documented and have a prepared fail safe process to revert the error in place for when it happens."
Admin
Yeah I'm on the side of the customer in this case. Present your module as a proof of concept is one thing. "Look, we could do this." But don't just cowboy code up something on the weekend, especially if you already know that the customer is super process-oriented!
And even if the customer is not super process-oriented, they might be annoyed that you spent time working on something you wanted to do instead of on something they wanted to do :D