• stupid old me (unregistered)

    I hope that's not my bank....

  • Crabs (unregistered)

    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...

  • Robert Hanson (unregistered)

    When the software gets in the way, users will figure out how to work around it. After all, the important work the tellers are doing is handing out money that belongs to the customer. The computer is already telling them how much to give out -- so why force the teller to type in a number the computer already knows? That just gets in the way of the teller doing their job.

    An example of people in the back room deciding what is best for the people up front, without doing any research or "looking over the shoulder".

  • (cs)

    I hate it when users do crap like that. Sounds like their user level needs to be dropped a few notches. No Process List for you!

  • Anonymous Coward (unregistered)

    Eventually, a user might stumble onto some workaround to avoid the new feature...

    If your user is that desperate to get away from it, it's not much of a feature.

  • Anonymous (unregistered)

    The real WTF is that the application didn't notice that it had unfinished transactions.

  • (cs)

    I call BS. I previously worked at a bank as a teller. A 'bankwide' problem of ctrl + alt + del is near impossible.

    Simply by the laws of probability, you are bound to find one person working there who will realize the error of ctrl+alt+del. Or maybe you will find at least one person there who will read the little confirmation window that says 'you may loose unsaved information and the machine may become unstable.'

    Please, please, please tell me that this really didn't happen in a corporation with thousands of employees.

  • Anonymous (unregistered) in reply to Anonymous Coward

    In this case, the user (the bank) and the actual end user (the teller) are separate entities with separate goals. The bank wants better reporting, so it's a feature to the bank (the actual paying user).

    That's like saying adding a feature to prevent the ATM from accidentally giving out too much cash isn't much of a feature as many people would like to override it and get extra cash for free.

  • SomeCoder (unregistered)

    Two comments on this:

    First, users that do stuff like this irritate the hell out of me. Use the freaking program correctly. Working around pieces of it only ensures that something critical will break down the road.

    Second and probably most important: if your users are desperate to work around a piece of the program, then that piece of the program needs to be changed. Management may have mandated something, but management doesn't know their head from their ass.

    I fight this battle against management nearly every day and I have never seen a case where management was right. You need to make software for the people who are using it, not for management who will never touch it, ever.

    This isn't the worst WTF I've seen on here, but it's a WTF on a bunch of different levels.

  • (cs)
    ...but it was a requirement from the bank that helped prevent errors.
    How does that work, exactly? The teller reads the amount due, counts it out to the customer, and then types in how much he gave. What, he's going to give the wrong amount by accident and then type in that wrong amount while looking at the correct amount on the screen?

    This is a really stupid idea. This doesn't "report" anything except that tellers know how to type in what they're reading.

  • Alan Balkany (unregistered)

    It's hard to make a system totally foolproof because fools are so ingenious.

  • (cs)

    There's a reason transactions were developed. Yes, the Users are stupid, but so are the developers for having software that will break from this.

  • MikeCD (unregistered) in reply to Crabs
    Crabs:
    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...
    Pretty sure you can't trap C-A-D, which is why it's used for the login sequence (to prevent lookalike keyloggers).
  • (cs) in reply to MikeCD

    You may not be able to hook it directly, but if needs be, you can disable Task manager with the group policy editor or (IIRC) a registry key.

  • (cs)

    I would rollback all the transactions for that customer and make the teller start over. Assholes.

  • Ornedan (unregistered) in reply to Anonymous
    Anonymous:
    The real WTF is that the application didn't notice that it had unfinished transactions.
    The application process was forcibly terminated. It doesn't matter if the application does or does not notice that there are unfinished transactions (it does), since the application isn't allowed to execute any more instructions. The only cleanup that happens is the OS releasing any OS-controlled resources the process held (eg, open files, network connections).
  • (cs)

    Sounds like poor design and a UI mistake, to me.

    I understand the need for it: banks want to know how much of each denomination they have, not just the net value of cash-in and cash-out. If the teller is to give $90.20, the system will say "4x $20, 1x $10, 2x dime". The customer may want 1x $50, 2x $20, 4x nickel.

    Thus, the teller would keep the customer happy by giving them the denomination they want, but then have to tell the bank that the money distributed in a different way than the default.

    A radio button saying "Default Denominations" and "Custom Denominations" would be better than forcing the teller to type it in each and every time.

    Although, I'd submit that it's probably just as invasive for the user to Ctrl+alt+del and kill the process as it would be to simply type the numbers in.

    Definitely a WTF

  • sol (unregistered)

    So is this a COBOL program or an ARGO data program? Not that there is much dif. I just wonder if they screen scrap the COBOL or use it directly.

    Wait what am I saying of course they wrote it in VB ;)

  • Anthony (unregistered)

    Maybe it's just me, but the real WTF seems to be that the permissions on the PCs that the tellers and clerks were using let them forcibly kill this process?

    Now, we hope that since it's a bank (implying there should be reasonably strict security rules in place) that they just happened to be running these apps in user space and weren't administrators on their machines, right? Or was the bank trying to practice security through employee ignorance?

  • Anonymous (unregistered) in reply to Ornedan

    You're right.

    But after the application restarted, it should see that it has unfinished transactions. Then, it could either send a message and halt all operations (for investigation), or tell the teller that the transaction was rolled back.

  • Foo (unregistered) in reply to Crabs

    But even Dennis Nedry had the sense not to knock out the Raptor fence

  • Foo (unregistered) in reply to Crabs
    Crabs:
    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...

    But Even Dennis Nedry didn't knock out the Raptor fence.

  • Dazed (unregistered) in reply to Robert Hanson
    Robert Hanson:
    When the software gets in the way, users will figure out how to work around it.
    In many cases of creative usage I'd be prepared to defend the user. But killing processes to save a few seconds work is rather like disabling the fire alarm to save having to step outside for a smoke.
  • Look at me! I'm on the internets! (unregistered) in reply to Anonymous
    Anonymous:
    You're right.

    But after the application restarted, it should see that it has unfinished transactions. Then, it could either send a message and halt all operations (for investigation), or tell the teller that the transaction was rolled back.

    But the transaction was actually completed. The customer has left the building with the cash in pocket. You can't roll it back.

  • DoneItBefore (unregistered) in reply to MikeCD

    MikeCD wrote:

    Pretty sure you can't trap C-A-D, which is why it's used for the login sequence (to prevent lookalike keyloggers).

    Ummm... I don't know what OS you are talking about, but you can trap Ctrl+Alt+Del in Windows. Doing so is highly not recommended, but I've had to do it before as part of enforcing application and system security.

    Trying to debug an application that disables C+A+D and then hangs is a major pain.

  • Dan (unregistered)

    Add a warning in red saying : "Hit Ctrl-Alt-Del and Die!!!"

  • Single Male (unregistered) in reply to ebs2002
    ebs2002:
    Sounds like poor design and a UI mistake, to me.

    I understand the need for it: banks want to know how much of each denomination they have, not just the net value of cash-in and cash-out. If the teller is to give $90.20, the system will say "4x $20, 1x $10, 2x dime". The customer may want 1x $50, 2x $20, 4x nickel.

    Thus, the teller would keep the customer happy by giving them the denomination they want, but then have to tell the bank that the money distributed in a different way than the default.

    A radio button saying "Default Denominations" and "Custom Denominations" would be better than forcing the teller to type it in each and every time.

    Although, I'd submit that it's probably just as invasive for the user to Ctrl+alt+del and kill the process as it would be to simply type the numbers in.

    Definitely a WTF

    If I know users, they'll just hit the "Default denominations" button every time, even if they handed out 9,020 pennies in little paper rolls.

    This is probably a clear-cut training issue - the procedure is there for a reason, and if people aren't following the procedure then you need to train them to follow the procedure, fire them, or change the procedure. If the users don't know the procedure and the reasons behind it then any part of the software that supports parts of the procedure that the user doesn't understand is just going to be treated as annoying bloat.

  • (cs) in reply to sol
    sol:
    ...scrap the COBOL...
    Freudian slip?
  • Zygo (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    Anonymous:
    You're right.

    But after the application restarted, it should see that it has unfinished transactions. Then, it could either send a message and halt all operations (for investigation), or tell the teller that the transaction was rolled back.

    But the transaction was actually completed. The customer has left the building with the cash in pocket. You can't roll it back.

    The application should return to exactly the same screen on restart, preferably with all the values in the text boxes that were present when Ctrl-Alt-Del was pressed. That way, not even unplugging the box will make that dialog go away.

    OTOH, there is a WTF in allowing the "kill process" feature to users in the first place. You could allow them to install software too, so that the next level of escalation is some kind of macro software combined with OCR to read the field values off the screen and enter them automatically...

  • Zygo (unregistered)
    To be clear, Jesse was serious about killing the process.

    Ummm, wasn't Sherri the one who was serious?

  • (cs)

    My guess is that the users must believe they've an awfully good reason to "cancel" the dialog if they're willing to do it by an elaborate process like working through the Windows Task Manager. It's probably closer to they being unable to do their job, not merely being inconvenienced.

    It could be a coding or requirements bug --maybe this uncancelable dialog is appearing when it shouldn't. Or maybe users are bringing it up accidentally, say by entering the wrong transaction amount. What's a user supposed to do then?

    An uncancelable dialog sounds like an inherently high-risk design, advisable only if you can guarantee that humans (whether customers, developers, or users) will never error.

    --RA

  • (cs)

    I propose the following amendment to their training:

    "Using Windows Task Manager to interfere with the operation of mission-critical applications is grounds for IMMEDIATE TERMINATION."

  • gary k (unregistered)

    "Ancient tribes that were present for the creation of the world 6,000 years ago passed down tales of the earth mother"

    Wow, really?? Even WTF isn't safe from the creationist / evolutionist nonsense?

  • (cs)

    I worked as a teller during college. This is 100% B.S.

    First of all, I could type numbers much faster than I could C-A-D and then find a process to kill. Second, I knew enough to question the wisdom of a forced stop of any banking application, especially when I was directly responsible for the totals.

    This is either completely made up, or "anonymized" badly.

  • (cs) in reply to Robert Hanson
    Robert Hanson:
    When the software gets in the way, users will figure out how to work around it. After all, the important work the tellers are doing is handing out money that belongs to the customer. The computer is already telling them how much to give out -- so why force the teller to type in a number the computer already knows? That just gets in the way of the teller doing their job.

    An example of people in the back room deciding what is best for the people up front, without doing any research or "looking over the shoulder".

    You couldn't be more wrong. If the customer wants $100 in cash, the computer might default to four 20's one 10 and two 5's every time.

    Obviously the customer could want something much different like 5 20's for example...

    My wife used to work for a bank. She was in charge of "ordering" money for the branch. They were only allowed (by either law or company regulation... not sure) to have a certain amount of cash in the branch at any given time, or they got penalized big time. Once a week they order from the feds how many 20's / 10's / 5's etc. etc. they need.

    They had a system much like this to help them keep track of how many of each denomination they had and what they needed to order for the next week... They couldn't afford to get waaay too many 100's and not be able to get enough 20's for example (which, running out of 20's was something that did happen from time to time)

    I'm not a fan of "people in the back room" messing things up for the peons, but in this case, it was a feature that actually saved them a lot of time and kept them from ordering wrong.

  • foo (unregistered)

    I'm trying to imagine a dialog box that is so cumbersome to use that killing and restarting the process is simpler. And I'm failing.

    Anyway, don't remove the Cancel button or disable ctl-alt-del, just add a 2-minute delay. That will make it faster to complete the dialog and they don't lose the ability to kill the task or back out of incorrect transactions.

  • (cs) in reply to bullseye
    bullseye:
    I worked as a teller during college. This is 100% B.S.

    First of all, I could type numbers much faster than I could C-A-D and then find a process to kill. Second, I knew enough to question the wisdom of a forced stop of any banking application, especially when I was directly responsible for the totals.

    This is either completely made up, or "anonymized" badly.

    My wife (former teller) can work a numpad at lightning speed. She can't type as fast as me, but put her in front of a numpad and she is crazy... I didn't think about that .

  • (cs)

    This makes me wonder if they have an ups...

  • (cs) in reply to MikeCD
    MikeCD:
    Crabs:
    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...
    Pretty sure you can't trap C-A-D, which is why it's used for the login sequence (to prevent lookalike keyloggers).

    WTF? You just need to know your GINA.

  • Alon (unregistered)

    I think the problem was not entering the amounts, but when the user did something wrong and wanted to CANCEL the transaction and couldn't, then they had to do the C-A-D, which I guess led to the transaction being logged incorrectly.

  • Bruce W (unregistered) in reply to MikeCD
    MikeCD:
    Crabs:
    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...
    Pretty sure you can't trap C-A-D, which is why it's used for the login sequence (to prevent lookalike keyloggers).

    Don't need to program this. You can use Group Policy to block access to C-A-D and Task Manager.

  • (cs) in reply to evanm
    evanm:
    There's a reason transactions were developed. Yes, the Users are stupid, but so are the developers for having software that will break from this.

    Transactions are acutally the problem. See, the teller would get the money out, give it to the customer, and then nicely rollback the transaction by killing the process. Voila, instant inconstistency...

  • Fabozz (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    Anonymous:
    You're right.

    But after the application restarted, it should see that it has unfinished transactions. Then, it could either send a message and halt all operations (for investigation), or tell the teller that the transaction was rolled back.

    But the transaction was actually completed. The customer has left the building with the cash in pocket. You can't roll it back.

    Of course you can. You've got armed guys standing right there by the door, you've got the customer's address on file... think outside the box, man!
  • S (unregistered)

    Huh? Then the whole transaction should be cancelled out. Jesse has to assume that the computer system will crash whenever, whereever, randomly, without warning and losing a single cent is simply not acceptable.

    "Ornedan": Presumably there's a server here? Maybe, oh, just maybe the program could detect unfinished transactions when it is restarted? Maybe the server should keep the transactions in a special 'unposted' state untill all the information is present and the transaction will either commit completely or not commit at all?! That way customers would complain in pretty blimmin' short order as the transactions wouldn't be in their accounts and the end-of-day balances won't talley for the cashier?

    If killing and restarting the process is faster than filling in this dialog box, this dialog box must be the most stupidly designed one ever.

    This begins to explain why bank tellers seem to spend ten minutes to do a simple balance inquiry.

    (And you can't capture C-A-D without admin rights. Custom GINA will do it.)

  • (cs)

    The computer's UI shouldn't even be involved in this. The computer should know what bills and coins are being dispensed. An electric eye could detect the removal of a bill and count it automatically. The coin drawers could maintain their own weight and calculate the number of coins removed based on that. Maybe the teller can confirm the total is correct, but if there's the possibility that they'd answer "no" then the system probably just to be engineered more thoroughly.

    To all the people who say "I hate it when users do stuff like this," I say, what exactly is it you hate? The fact that they find your software hard to use? It takes a reasonable amount of intelligence to write software, it takes much more to write software that is easy to use. The problem isn't stupid users...

  • Gitsnik (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    Eventually, a user might stumble onto some workaround to avoid the new feature...

    If your user is that desperate to get away from it, it's not much of a feature.

    I dunno... our helldesk seems to find more workarounds than the user. Especially when they're flat out...

  • Ornedan (unregistered) in reply to S
    S:
    Huh? Then the whole transaction should be cancelled out. Jesse has to assume that the computer system will crash whenever, whereever, randomly, without warning and losing a single cent is simply not acceptable.

    "Ornedan": Presumably there's a server here? Maybe, oh, just maybe the program could detect unfinished transactions when it is restarted? Maybe the server should keep the transactions in a special 'unposted' state untill all the information is present and the transaction will either commit completely or not commit at all?! That way customers would complain in pretty blimmin' short order as the transactions wouldn't be in their accounts and the end-of-day balances won't talley for the cashier?

    If killing and restarting the process is faster than filling in this dialog box, this dialog box must be the most stupidly designed one ever.

    This begins to explain why bank tellers seem to spend ten minutes to do a simple balance inquiry.

    (And you can't capture C-A-D without admin rights. Custom GINA will do it.)

    See what Dennis Troller said.

    To elaborate: The transaction is not (as far as I can tell based on TFA) related to the customer's account. It's about recording how much of each denomination has been handed out. The problem is that the teller hands out the money, but kills the program before committing the transaction -> inconsistency between records and real world.

    And yes, I guess it should record the transaction-in-progress somewhere other than just in memory.

  • Jesse B (unregistered)

    Hi guys. I'm the submitter of this WTF. A few comments:

    1. It's probably not your bank. But I've probably got other WTF stories that are about your bank.

    2. Our software, by default, did allow cancellation of the cash counter dialog. This bank's management actually paid us to remove it for them. I couldn't find any record of when or why, though, when I was researching the issue.

    3. Our software predated the Golden Age of Enterprisyness. It was written back when personal computers were powerful and independent! When relying on "servers" was a sign of weakness! While the official recordkeeping did still go through screen-scraped TTY emulation to the host mainframes, anything else that a branch's computers needed to communicate with each other was done with shared files and network file locks.

    The platform did a fairly good job of tying together the sea of disparate systems in use by the bank, but there was no way to eliminate every possible fracture in atomicity.

    1. I can't remember exactly which OS it was. Possibly Windows 98 or ME. Maybe 2000, but I doubt it. The networking was Novell, not Windows. Fancy concepts like user privileges would have to wait a few years; back then, IT folks used to LOVE moving from workstation to workstation, manually installing and configuring everything from a portfolio of CDs. Sometimes, as a game, they'd configure one or two of the machines differently, just to see how long it took for people to notice.

    2. I certainly don't claim that each and every teller used the control-alt-delete "cancel button", but the problem existed in multiple branches.

    3. I don't know when or why the tellers were deciding to "cancel" their transactions. It's not just about typing speed though - it probably involves wads of cash, piles of coin, open cash drawers, very small counter spaces, and irritable customers.

  • (cs) in reply to MikeCD
    MikeCD:
    Crabs:
    Disable Ctrl-Alt-Del, then. Make it play a sound byte...like "Ah ah ah, you didn't say the magic word"...
    Pretty sure you can't trap C-A-D, which is why it's used for the login sequence (to prevent lookalike keyloggers).

    Remove the ctrl key from the keyboard (or one of the others). Hopefully they don't have to use all three of them for normal use of the app.

    For added security, glue the keyboard into the USB/PS2 port.

  • Al (unregistered)

    Let's be completely honest here; you know that if you trap C-A-D these same users will take the time to restart the whole machine. It's just a fact. If killing that process and restarting the app isn't a problem for them, a reboot isn't either.

    Nature continues to amaze with a dazzling array of increasingly intelligent idiots. Your next task will wind up being removal of the power button or encasing their terminal so they don't have access to the power cords.

Leave a comment on “Assisted Processicide”

Log In or post as a guest

Replying to comment #140674:

Log Out

« Return to Article