Users Don’t Care About Your Tech Stack
-
Banks.
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it's in part due to risk aversion, ignorance and inertia. But it's also because, if in the end result is the same, then the tech stack doesn't matter.
Very few people are tech fanatics, most people want results. They care when the products don't work. They don't care how you fix it as long as you fix it in a reasonable manner, within an acceptable timeframe at an affordable price.
Doesn't matter if the customer is a billion dollars bank or a social network. Debbie thinks javascript is when the barista puts her initials on her latte and rust is something to fear when it shows up under her car. Too many devs forget this.
That's actually the area I currently work in, though not banking specifically. We do financial software for small governments. All the software was written in the 80s and 90s and we're babying it along well into the 2030s in all likelihood. Those old systems require very specific environments which we're now trying to emulate in the cloud. It's a very specific stack at the end of the day. And because this small government segment is currently undergoing consolidation I know what we see is the norm.
Thankfully I just have to maintain the cloud infrastructure and making it as reliable and secure as possible.
-
Banks.
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it's in part due to risk aversion, ignorance and inertia. But it's also because, if in the end result is the same, then the tech stack doesn't matter.
Very few people are tech fanatics, most people want results. They care when the products don't work. They don't care how you fix it as long as you fix it in a reasonable manner, within an acceptable timeframe at an affordable price.
Doesn't matter if the customer is a billion dollars bank or a social network. Debbie thinks javascript is when the barista puts her initials on her latte and rust is something to fear when it shows up under her car. Too many devs forget this.
In contrast, banks all universally moved to single page apps lately, and every one of them sucks. Some suck more (we don't support you having more than one tab open while you are researching stocks) and some suck less (what is the back button for, anyway? Just ignore it). But they all suck.
And yes, users do care about using shitty stacks when they make shitty results.
-
That's actually the area I currently work in, though not banking specifically. We do financial software for small governments. All the software was written in the 80s and 90s and we're babying it along well into the 2030s in all likelihood. Those old systems require very specific environments which we're now trying to emulate in the cloud. It's a very specific stack at the end of the day. And because this small government segment is currently undergoing consolidation I know what we see is the norm.
Thankfully I just have to maintain the cloud infrastructure and making it as reliable and secure as possible.
As long as you remember that the cloud is just someone else's computer that they have admin rights on.
-
In contrast, banks all universally moved to single page apps lately, and every one of them sucks. Some suck more (we don't support you having more than one tab open while you are researching stocks) and some suck less (what is the back button for, anyway? Just ignore it). But they all suck.
And yes, users do care about using shitty stacks when they make shitty results.
If your users are aware and complaining about your tech stack, you failed as a Dev. The stack had nothing to do with it, its on you.
-
This post did not contain any content.
They care about your site being compromised or down, and your choice of tech stack has a lot to do with how likely those things will be.
-
Banks.
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it's in part due to risk aversion, ignorance and inertia. But it's also because, if in the end result is the same, then the tech stack doesn't matter.
Very few people are tech fanatics, most people want results. They care when the products don't work. They don't care how you fix it as long as you fix it in a reasonable manner, within an acceptable timeframe at an affordable price.
Doesn't matter if the customer is a billion dollars bank or a social network. Debbie thinks javascript is when the barista puts her initials on her latte and rust is something to fear when it shows up under her car. Too many devs forget this.
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it’s in part due to risk aversion, ignorance and inertia. But it’s also because, if in the end the result is the same, then the tech stack doesn’t matter.
I've done extensive consulting for financial firms, including mainframe-replacement projects, and that's not the reason. There are two reasons: banks regard IT as a cost center, so they systematically underinvest. They never budget for lifecyle maintenance, they just kick the can down the road as far as they can. In addition to that, hardly anyone who wrote that COBOL code is still alive, and when it was written in the 1970s or 80s, the requirements and design were seldom documented, and after decades of code maintenance, they're no longer accurate anyway. So to replace that COBOL, you have to reverse-engineer the whole business process and the app that embodies it. And you can't do like-for-like replacement, since a lot of the business process is actually workarounds for the limitations of that legacy system. And it's even worse than that: sometimes that COBOL has some custom IBM 360 assembler behind it, and nobody remembers what that shit does either, and finding people who know that, or CICS, or the quirks of ancient DB/2 versions, is even harder than finding someone skillful who can write COBOL. So until there are new requirements, usually new regulations that cannot be weaseled out of, they let that sleeping dog lie.
-
In contrast, banks all universally moved to single page apps lately, and every one of them sucks. Some suck more (we don't support you having more than one tab open while you are researching stocks) and some suck less (what is the back button for, anyway? Just ignore it). But they all suck.
And yes, users do care about using shitty stacks when they make shitty results.
every one of them sucks
They went to the cheapest bidders, and those poor devs in Chennai have no fucking clue about proper UX design.
-
I would say, it's them caring about the product and their needs, rather than the underlying stack.
I would say, it’s them caring about the product and their needs, rather than the underlying stack.
That's the idealistic fairy tale that only the most fatuous of UX people believe. But anyone who looks at any process closely enough will soon realize that a system's stakeholders often have objectives that are in conflict with each other. It's not all about the users, it's about low operations cost, it's about collecting and selling data on user behavior, it's about minimizing support costs, improving monetization, up-selling, cross-selling, and a number of other things the users neither want nor need. And that is the root cause of enshittification.
-
What truly makes a difference for users is your attention to the product and their needs.
This is the most important thing here. Additional thing to consider that in my experience devs regularly overlook: how easy is it to implement and support?
OK, now take that to the next step: what do you do when optimizing ease of implementation and support limits the user needs that can be met? How do you decide which objective is higher priority?
-
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it’s in part due to risk aversion, ignorance and inertia. But it’s also because, if in the end the result is the same, then the tech stack doesn’t matter.
I've done extensive consulting for financial firms, including mainframe-replacement projects, and that's not the reason. There are two reasons: banks regard IT as a cost center, so they systematically underinvest. They never budget for lifecyle maintenance, they just kick the can down the road as far as they can. In addition to that, hardly anyone who wrote that COBOL code is still alive, and when it was written in the 1970s or 80s, the requirements and design were seldom documented, and after decades of code maintenance, they're no longer accurate anyway. So to replace that COBOL, you have to reverse-engineer the whole business process and the app that embodies it. And you can't do like-for-like replacement, since a lot of the business process is actually workarounds for the limitations of that legacy system. And it's even worse than that: sometimes that COBOL has some custom IBM 360 assembler behind it, and nobody remembers what that shit does either, and finding people who know that, or CICS, or the quirks of ancient DB/2 versions, is even harder than finding someone skillful who can write COBOL. So until there are new requirements, usually new regulations that cannot be weaseled out of, they let that sleeping dog lie.
The underinvestment is absolutely on-point. Very few banks see them as a platform business and think that their banks can do deals on excel sheets
-
This post did not contain any content.
Most if not all prefer a particular tech stack based on how familiar they are with the ecosystem around it, not because of ego as most think. I would never prefer PHP based tech stack. Why? Because I have like 0 idea of that particular ecosystem.
-
Do you know why banks are still running COBOL on new, old architecture, IBM mainframes? Sure, it’s in part due to risk aversion, ignorance and inertia. But it’s also because, if in the end the result is the same, then the tech stack doesn’t matter.
I've done extensive consulting for financial firms, including mainframe-replacement projects, and that's not the reason. There are two reasons: banks regard IT as a cost center, so they systematically underinvest. They never budget for lifecyle maintenance, they just kick the can down the road as far as they can. In addition to that, hardly anyone who wrote that COBOL code is still alive, and when it was written in the 1970s or 80s, the requirements and design were seldom documented, and after decades of code maintenance, they're no longer accurate anyway. So to replace that COBOL, you have to reverse-engineer the whole business process and the app that embodies it. And you can't do like-for-like replacement, since a lot of the business process is actually workarounds for the limitations of that legacy system. And it's even worse than that: sometimes that COBOL has some custom IBM 360 assembler behind it, and nobody remembers what that shit does either, and finding people who know that, or CICS, or the quirks of ancient DB/2 versions, is even harder than finding someone skillful who can write COBOL. So until there are new requirements, usually new regulations that cannot be weaseled out of, they let that sleeping dog lie.
I also worked on finance tech once. I agree with all you said, but the point is that a fancy sales pitch about a new bleeding edge server tech stack is not gonna change any of that because the customer doesn't care about the same things that developers care about.
-
They care about your site being compromised or down, and your choice of tech stack has a lot to do with how likely those things will be.
Yeah, I don’t care about the materials my coffee maker use, but I hope the company that makes them does.
-
System shared this topic on
