• robert frist (unregistered)

    Frist frost

  • (nodebb)

    There are no "requirements", only "desirements"..... (think about it and re-read it a few times).

  • Stu (unregistered)

    "Focus on adding features that fit into the overall product vision."

    So you're going to tell the customer (internal or external) that they can't have that feature, required by a new business need, because it doesn't fit the developers' "vision"? No. Software is a tool. It exists solely to serve the needs of the user. If your product doesn't meet the needs of its customer, it's deficient, regardless of your "vision".

  • Ollie Jones (unregistered)

    Lookit that UI. From Java's early days. And that Flexcube thing is Oracle's.

    Oracle's the new Computer Associates. The buy up legacy enterprise software and milk enterprise customers for big maintenance fees until they get angry enough to invest in modernization, usually when it's too late.

  • Hal (unregistered) in reply to Stu

    "If your product doesn't meet the needs of its customer, it's deficient, regardless of your 'vision'"

    I would argue that is only true as long as it isnt a case of the customer trying to use chisel as a screw driver. Trying to accommodate them in that case is going to ruin your tool as surely as turning screws with the chisel will leave it unsuitable for wood work.

    I have seen business users try to solve technical problems and approach developers with bizarre requirements "like I need be able to create users that can't login and are not visible even at the tenant admin level". You could of course add some "hide from tenant" and "Account Disabled" flags or and give them some new checkbox widgets. - You'd be wrong to it. If you quiz'd them a little more you'd learn well the issue is our per user metrics are wrong because the XYZ corp tenant has 500 users really but they all share a single password - we told them this is a terrible idea but they are the customer yadda yadda yadda.

    So what YOUR customer really needs is to have the addressbook separated from whatever notion of accounts you presently have, and a one to many relationship between accounts and addressbook entries. Than the reporting subsequently adjusted. If you just blindly implement their requirements you are effectively turning the data model over to the end user in this example, and that won't end well.

  • Best Of 2021 (unregistered)

    I wonder what their projected 'savings' from using outsource monkeys was and how that stacks up to the $500m they're down.

    Talking of UX blunders, who designed this site and how does it make sense to you that there is no single page that shows you the article and comments? I get not loading the comments with every article (performance), but when I click from the article to view the comments, I already loaded the article so surely you can load the comments inline at the bottom of the page.

  • LCrawford (unregistered)

    It would be interesting to see a properly trained UI Architect's vision of how this screen should have been done.

  • Cheats Never Prosper (unregistered) in reply to Stu

    Product vision, not "the current dev's current vision of the product"

  • (nodebb)

    @Stu - . If your product doesn't meet the needs of its customer, it's deficient, regardless of your "vision"...... Untrue... Consider the BEST spreadsheet program, I need a 3D imaging tool... is that spreadsheet "deficient" because the producer of that product does not meet my needs.... or is is simply me chosing a totally inappropriate product..

    @Hal - Thanks fo rthe example of what I was talking about in my original comment.

  • (author) in reply to Stu

    So, I'll say this: the customer doesn't know what they want. I've watched customers run right off the cliff with features that they say they need, and then realize only after the product ships that they're an anti-feature. Real example: I built a system that allowed lab techs to schedule calibrations of scientific equipment. When it came time to design the notification system, the customer requested that we send basically a billion notifications. Send one a month out, two weeks out, a week out, a day out, an hour out, blah blah blah. We warned them that this was too many notifications (via email no less). No one would want them, it'd be annoying, it'd be confusing, etc.

    No, they definitely wanted all those notifications.

    It was live for a week before they came back: "It sends too many notifications."

    We got lucky there: they realized it was a mistake. It didn't stop them from making the mistake in the first place, but at least they corrected the mistake.

    That particular application was a replacement for an older application. The older application had every feature the customer thought they wanted, when it was built. More features than they needed, most of the time, and most users only used a slice of it. You know what feature the application didn't have? The ability to delete or decommission an instrument. Every scale that the company had ever purchased had to be in the database, and had to be assigned to a user, and sent out notifications for calibrations, despite being chucked in the dumpster a decade ago.

    Sometimes, the person who has the least understanding of what they need from the application is the application's user.

  • (nodebb)

    The most puzzling part about that case is why the creditors were allowed to keep the money that was incorrectly sent.

  • (nodebb) in reply to R3D3

    why the creditors were allowed to keep the money

    Because Citibank actually owed them the money. They tried to roll the money from the account that the original investors invented in to an account for "select" customers that they were hoping to prioritize payment to. Had they made the transfer it would have simply been a case of a risky investment that didn't work out because of choices the manager made. But, since the manager didn't actually make those bad choices they weren't allowed to get the money back for a "do over".

  • RLB (unregistered)

    And another thing that makes my neckhairs stand on end: "Every sprint" in an article about banking software. I do not want my life savings handled Agilely, TYVM. Save that for social media apps.

  • Whatever (unregistered) in reply to R3D3

    There is nothing puzzling abut being allowed to keep the money, because there is an expectation that in some point in time you will be paid that money. This is not a case of $$$ accidentally being sent to an account it wasn't meant to be sent to, and to who didn't have any rights to that money. In this case amount sent equaled exactly the amount owed (to the dollar), and the law allows for you to keep the money in that particular case.

    And as for the offshore contractor. It's not just all on him. Two other internal people had to sign off on the transfer before it was executed.

  • (nodebb) in reply to R3D3

    The Matt Levine piece explains it pretty clearly. The creditors were owed the money. The creditors were sent the money. Exactly the amount they were owed. Debt discharged. Why think it was done incorrectly?

    How often have you been told "Oh, sorry; I didn't mean to pay you what you were owed. Give that money back, please."

    They had no reason to think it was a mistake until a day later. At which time they were probably still feeling relieved at ending a relationship that was becoming increasingly toxic.

  • Debra (unregistered)

    $1,137 per hour? That must be a typo. The real rate is most definitely $1,337.

  • Hal (unregistered) in reply to Jaime

    My understanding was Citi not only owed them the money and sent a payment EARLY for the exact amount they owed. Obviously this a bad choice for Citi because money has time value. That is money they could have been using for other investments for some months or whatever. However the judge ruled the creditors did not have to return money that was ultimately owed to them anyway and should not be reasonably expected to view a payment as an error when it was done in the anticipated amount. They had a right to accept the funds and take actions and make their own decisions based around the assumption the transaction was a settled and legitimate.

    Think of this way. Lets say you owe 20,146.06 on your mortgage principle. You send that EXACT amount to your loan servicing company. In response they close your account and transfer the title on the property to your exclusive possession. A couple days latter you realize you'd had a few to many beers while playing in Quicken and I thought "cool I can write a check for that right now" and did so, but darn it you need to pay your daughters college tuition. So you phone your mortgage lender and ask them to send the money back, they tell you "umm yeah can't so much do that, but if you don't mind the paying the origination fees we can set you up with a nice HELOC"

    Citi was crying that this was somehow unfair.

  • (nodebb)

    The worst part are the users who think they need everything they asked for, and all at once, to work. The "all or nothing" approach is very rare in actual circumstances but the business users always think they can't do anything with 90% functionality or getting features added piecemeal.

  • (nodebb) in reply to RLB

    I do not want my life savings handled Agilely, TYVM. Save that for social media apps.

    I'm of the opposite opinion. If there's a bug in my financial institution's software, I want it fixed as quickly and efficiently as possible.

  • Cidolfas (unregistered) in reply to Hal

    This. At our company we try to ask our users, "Give us problems, not solutions." We don't want them to design wireframes or describe processes. We ask them what they're trying to do, and what their pain points are, then we Sherlock Holmes it until we get to the actual problem and we suggest the fix for it. It's actually quite rare that we end up building the thing they originally wanted us to build.

  • Best Of 2021 (unregistered) in reply to Stu

    Software is a tool. It exists solely to serve the needs of the user.

    It's a tool, yes. But it shouldn't try to be all tools. Sometimes a hammer should just be a hammer, it shouldn't also try to be a screwdriver, power drill and tap.

    And even if there is a legitimate business need that should be in scope for your tool, your feature should be designed around the problem, not what the customer thinks the solution is (which requirements are often written as). That way lies an incoherent and unusable mess.

  • (nodebb)

    I used to work for a company which was a vendor to Bank of America. From my experience, the level of incompetence up and down the hierarchy there was overwhelming. Sometimes you wonder how they're still in business.

    Looks like Citi is not much different. What a surprise.

  • (nodebb)

    One question is, if Citi is acting as a servicing bank, why is it responsible for the debt? Does Revlon now owe this money to Citi?

  • (nodebb) in reply to TheCPUWizard

    Consider the BEST spreadsheet program, I need a 3D imaging tool... is that spreadsheet "deficient" because the producer of that product does not meet my needs.... or is is simply me chosing a totally inappropriate product..

    In terms that are relevant to consumer protection law, no, of course the spreadsheet is not deficient. That would be like saying that a hammer is deficient since I wanted a torque wrench, but bought a hammer anyway. The specific terminology that should be in good consumer protection law is "unfit for the purpose for which it is sold", which contains a key distinction. If the rack containing the hammers in the hardware store is clearly marked as containing hammers, and there aren't any loose hammers in the rack that's equally clearly marked as containing torque wrenches, then I have no grounds for complaint if I buy a hammer intending to use it as a torque wrench.

    ==> Purpose for which it is sold = hammer (in a rack full of other hammers, clearly marked as hammers)

    ==> Purpose for which it is bought = torque wrench (because I'm an idiot)

    So in your hypothetical case:

    ==> Purpose for which it is sold = spreadsheet

    ==> Purpose for which it is bought = 3D imaging tool

    But if you use a different program, one that it sold as a 3D imaging tool, and there's something related to 3D imaging that it cannot do, then it is deficient.

  • (nodebb) in reply to Hal

    My understanding was Citi not only owed them the money and sent a payment EARLY for the exact amount they owed. Obviously this a bad choice for Citi because money has time value.

    This is an explanation for why they get to keep the money, but isn't an explanation for why Citi had no intention of sending it in the first place. The real kicker here is that Citi planned on screwing these people, but "accidentally" gave them exactly what they were owed. If the intention issue didn't exist, then Citi would never have asked for the money back in the first place and this whole thing would be a non-issue. Citi didn't just send the money early, they fully intended to completely screw these investors.

  • Foxglove (unregistered)

    'Or the software bug that is causing hundreds of inmates at Arizona prisons convicted of nonviolent offenses who should be released early for completing voluntary classes from getting their due release'

    That story was total nonsense. It isn't a bug. It's an additional feature which wasn't required when the contracts were signed. The calculations are done manually, and no-one was kept imprisoned for longer than they were supposed to be.

  • grasshoppa (unregistered)

    I'm convinced that NO ONE knows how to do UI development, and looking at modern applications you can't convince me otherwise. You'd think, of all companies out there, MS would have the funds to properly develop an intuitive interface...but it's a CF of competing "visions".

    UI is all garbage today.

  • Air Conditioning in the 80s (unregistered)

    That sensei from The Art of Self Defense. Turns on the computer. Opens a Spreadsheet. It's all just chops. Types one "X". Clicks save. Clicks close. Turns it off. Awareness of environment, what he's doing, and focus. Now that's how you use a computer.

  • Brian Boorman (google) in reply to Jaime
    The real kicker here is that Citi planned on screwing these people, but "accidentally" gave them exactly what they were owed. If the intention issue didn't exist, then Citi would never have asked for the money back in the first place and this whole thing would be a non-issue. Citi didn't just send the money early, they fully intended to completely screw these investors.

    This is just blatantly false.

    Let’s recall that the lawsuit concerns wire transfers from August 11, 2020 regarding Revlon’s 2016 Loan. In 2016, Revlon acquired Elizabeth Arden, Inc. The deal was partially facilitated by a seven-year, $1.8-billion loan. Citibank serves as the administrative agent and collateral agent for the loan.

    On August 11, 2020, several months of accrued interest came due under a credit agreement. The interest payment was to be processed by Citibank in its capacity as administrative agent. No other amount was due at the time, and Revlon transferred no additional funds to Citibank.

    Source

  • (nodebb)

    @Remy - "So, I'll say this: the customer doesn't know what they want. I've watched customers run right off the cliff with features that they say they need, and then realize only after the product ships that they're an anti-feature. "

    That is why it is critical to get working software into the hands of the customers early and frequently. If they are getting new versions ever few (1-4) weeks with incremental value, then it will quickly become obvious which elements are "anti-features" and the project pivoted.

  • (nodebb)

    @STeve - I don't disagree. However Hal's post did not include any such constraints. I believe my example met the selection/bounding criteria provided by Hal.

  • Loren Pechtel (unregistered) in reply to Hal

    | I have seen business users try to solve technical problems and approach developers with bizarre requirements "like I need be able to create users that can't login and are not visible even at the tenant admin level". You could of course add some "hide from tenant" and "Account Disabled" flags or and give them some new checkbox widgets. - You'd be wrong to it. If you quiz'd them a little more you'd learn well the issue is our per user metrics are wrong because the XYZ corp tenant has 500 users really but they all share a single password - we told them this is a terrible idea but they are the customer yadda yadda yadda.

    Yup--I like having the proposed solution from the users but I also want to know what the underlying issue is because all too often they're trying to tweak rather than step back and do it right.

  • ooOOooGa (unregistered)

    While the shady business practices of banks and the arguments of lawyers are amusing to read about, my takeaway from this is regarding the cost of technical debt.

    The technical debt in this case was the outdated checkboxes on the UI with obscure names which prevented the one checkbox with the proper name from actually doing anything. And the fact that the program wasn't capable of handling the multiple-lender loan account separately for each of the lenders.

    So because Citibank didn't want to pay down their technical debt for their loan management software, they instead paid down (someone else's) actual debt.

    But at least now we have an actual monetary value to assign to technical debt in this case. It can join the others.

    floating point rounding errors - Patriot Missile defense system failure - cost lives.

    UI race conditions - Therac-25 - cost lives.

    Integer overflow and incorrect error handling - Ariane 5 - $370 million.

    Outdated UI elements - Citibank erroneous loan payoff - $900 million.

  • Airdrik (unregistered) in reply to Brian Boorman

    Adding to what Brian Boorman pointed out. Citi was the middle-man between Revlon who ultimately owed the debt and the investors (providing a buffer between Revlon and the investors so that Citi can manage the interactions and obligations with each investor while Revlon only needs to worry about its interactions and obligations with Citi). Revlon we can assume had full intention of paying all obligations associated with the debt as contractually required. That Citi accidentally payed off the debt early meant that they were paying the $900M of Revlon's debt out of their own cash reserves (cash that they probably had earmarked for other investments which had to be diverted to account for this accident).

  • Wizofaus (unregistered) in reply to jkshapiro

    Perhaps but I'd tend to agree that the Agile mindset is often "move fast and break things": I.e. get your changes deployed quickly and be ready to respond quickly if there are unexpected outcomes. Fine for many applications but not ideal for safety- critical systems (pretty sure inflight control systems and nuclear power plant systems aren't built this way). But you can still use many of the ideas from agile methodologies and combine it with QA and release gating practices that would be as expected for banking systems.

  • (nodebb)

    @Wizofaus.... "pretty sure inflight control systems and nuclear power plant systems aren't built this way" -- I have worked on many safety critical systems, and the answer is both a "yes and no". The key is to have highly sophisticated simulators so that the customers can experience the software and try the features (fast, and breaking things) without an actual physical risk.

  • Sole Purpose Of Visit (unregistered) in reply to Mr. TA

    Things went downhill at BofA.

    Don't forget -- they span off VIsa (a not for profit company, indeed) and threw probably the top 50% of their tech guys into it. Thank Dee Hock for that. I worked for another spin-off, based in Concord (used to be the cheap, tech hub for BofA) , which was meant to be the new Internet version of Visa. Bugger of a commute is Concord. And the spin-off (pre-2000 startup craze) didn't really work, what with it being based on a Mumps architecture coupled with Corba.B

    I can't say I remember this fondly, because fond is not the word, but I do remember it definitively: even at spinoff.com, we all got to listen to a phone call from whatever worthless piece of Texas banking conglomerate shit had just bought BofA, and ... [B}every single word that the new CEO said was worthless demotivating shit.[/B]

    Didn't make any difference to me, because I was a contractor. But hundreds, possibly thousands, of dreams died that day. Not just techies. Tellers. HR people. Just about everybody.

    Dee Hock had a dream for Visa, and whatever you think about Visa (pre the point where it stopped being a not-for-profit company, allowing which transition was just diseased), it was a fine place to work. I did three spells there. I have no complaints.

    But, BofA? Worthless crap. Do not, under any circumstances, go near it.

  • Sole Purpose Of Visit (unregistered) in reply to Wizofaus

    Would you care to identify the systems for which Agile is fine? (You can define Agile however you like. There are dozens of books and many, many online tutorials.)

    Agile, whatever it is, has a number of useful insights, invariably borrowed from somewhere else (no bad thing), and I'm awfully glad that they've stopped talking about bits of their process as "sashimi" or "suppoku" or "transitive zen woke intersectional theory" or whatever.

    But only some of those insights work in any given environment, from safety-critical right up to cretin web design.

    The key is to pick the insights and to that work for your organisation (ie organically: easy fit for fattie techs) and to pour scorn on the agile process divots.

  • Clark (unregistered)

    Is that a Borland checkmark button?

  • (nodebb) in reply to Sole Purpose Of Visit

    The reality of "agile" is apparently quite often just "buzzword agile". Importing the terminology, increasing stress levels by giving more frequent reports, but otherwise not changing a thing.

  • Steve (unregistered) in reply to R3D3

    The reality of "agile" is apparently quite often just "buzzword agile". Importing the terminology, increasing stress levels by giving more frequent reports, but otherwise not changing a thing.

    You forgot the bit where it's now solely the developers' fault that the business people don't understand and can't explain their own processes.

  • (nodebb) in reply to Wizofaus

    I'd tend to agree that the Agile mindset is often "move fast and break things"

    "Move fast and break things" is definitely a thing, but it's not Agile. Check the Agile manifesto (https://agilemanifesto.org/): the priority there is clearly working software. Each increment doesn't have to do much, but it does have to do it well.

    In real life, though, I'd agree that a lot of people who think they're "doing Agile" really aren't.

  • (nodebb)

    From the article:

    ...not only did the GSA build a website, but they invested in the SEO necessary to make it top of Google organic search

    They may not have needed to do much. Google does its best to prioritise high-quality results, and the usability.gov content is excellent. Plus it's government, which also gets a boost.

  • (nodebb) in reply to Brian Boorman

    This is just blatantly false.

    See https://clsbluesky.law.columbia.edu/2021/02/24/how-the-litigious-bird-caught-the-banque-worm/

    All seemed to go according to plan until the spring of 2020, when Revlon — which had fallen into financial difficulties necessitating additional capital infusions — executed a series of transactions that effectively undercut the collateral backing the loan.

    No one was going to get paid back..... and then they did.

  • MiserableOldGit (unregistered)

    I've seen much worse than that ... it's just a GUI wrapped around some ancient text based thing, probably sending messages back to VMS or AS-400 or something. There's actually not much wrong with it so long as it has trained operators in front of it.
    Even with trained operators, something like that should have an approval process.

    In the end, Citibank owed that money to those people and "accidently" paid them when it intended to sit on the money and do other things with it ... excuse me if I don't shed tears over the outcome.

    In the end, their attempt to bilk their creditors failed because they were being cheap, sod the IT, serves them right in both ways.

  • mushroom farm (unregistered) in reply to jkshapiro

    i have not yet seen any evidence that Agile posturing actually pays off in terms of speed or efficiency. any "Agile Coach" is just so much dead weight on the payroll

  • mushroom farm (unregistered) in reply to Steve

    oooh that one is my favorite. once spent two full months asking the PMs what the business conditions were for my company to regard a customer as a "paying customer". the CFO had to get involved in the end

  • CmdrKien (unregistered)

    Everyone's getting on the Citibank issue, but no one's commented on Hawaii: https://www.washingtonpost.com/news/the-switch/wp/2018/01/30/heres-what-went-wrong-with-that-hawaii-missile-alert-the-fcc-says/ It wasn't a UI failure there. The guy who issued it actually thought it was a real thing.

    There is a UI issue though, based on public sources.

  • nasch (unregistered)

    "Even with trained operators, something like that should have an approval process."

    It did. The payment was approved by two different people, also using the same or similar UI so they also didn't catch the problem.

Leave a comment on “UI That Looks Like $900 Million Bucks”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article