I used this tool at the State of [redacted] Dept of Taxation to develop the whole system. The database was Oracle (I think) and we would write the backend code as such:
1. Copy the 2019 code function "VERIFY_TAX_RULE_147B_2019()" to "VERIFY_TAX_RULE_147B_2020()"
2. Follow this list of rule changes for this rule to change the function
3. If there are any 2019 functions in this function, make a ticket to copy+paste those in a similar fashion for some other developer
4. Close ticket
5. Get another ticket
The front end for the forward-facing revenue agents would also get updated in a similar fashion, one Power Builder form for each year and window they needed, so if you opened 2020 taxes you would get "WIN_FORM_PAGE_A317_2020" and if you opened 2019 or 2018... you get the idea.
It was a horror from the usual "software engineering practices" standpoint on stuff like code re-use, but it was super easy to do and based on the risk analysis it was the best/easiest/cheapest solution to be able to test, review, and ensure the accuracy of EVERY tax rule we implemented with iron-clad certainty.
Someone in QA would just go to each function, make sure it calculated things correctly based on the requirements, and do a few other checks. We had a big QA department that would do test driven development on each pull request (if it failed, you went back to fix it again, so since we used Visual Source Safe we ENSURED it worked the first time; you know what I mean if you used VSS) and sit down with the developer for each function and go through it in a heavy review. I can't imagine trying something like that in React or whatever, you could never ensure the software would always behave the same way each time with the network latency and huge underlying security concerns for the framework and a bunch of other issues we would have had to overcome to prove it worked correctly every time. Backend frameworks would be even WORSE for our risk profile.
Most importantly: no one cared what the damn UI looked like as long as all the buttons and text boxes were there in the designated configuration. They were all Windows 95-style UI boxes and I doubt that the front desk agents would have been happier to use some Reactified "pretty" stuff.
The story is just to say that I agree with you wholeheartedly that the UI/UX space has exploded with useless garbage you don't need in a simple, boring business tool and 95% of software is just that, simple and boring.
Each such VB-influenced tool all had their weak points. But overall they seemed moving in the right direction as each vendor learned from each other's mistakes. Power-Builder's difficulty in code share-ability was a specific design flaw of the product, not of the general concept, and perhaps fixable on a later version.
As far as most business software being "simple and boring", I wouldn't necessarily call it "simple", for the domain rules can get intricate. But it doesn't need buzzwords like blockchain web-scale AI or what not.
Desktop GUI's reached a pinnical around the late 90's and web UI's still cannot compete on simplicity and functionality. DOM-based emulators tend to break on browser version updates. We need a dynamic GUI-over-HTTP standard to allow us real GUI's on a browser or browser-like interface. Something like YAML, but more interactive. #MakeGuisGreatAgain!
I used this tool at the State of [redacted] Dept of Taxation to develop the whole system. The database was Oracle (I think) and we would write the backend code as such:
1. Copy the 2019 code function "VERIFY_TAX_RULE_147B_2019()" to "VERIFY_TAX_RULE_147B_2020()"
2. Follow this list of rule changes for this rule to change the function
3. If there are any 2019 functions in this function, make a ticket to copy+paste those in a similar fashion for some other developer
4. Close ticket
5. Get another ticket
The front end for the forward-facing revenue agents would also get updated in a similar fashion, one Power Builder form for each year and window they needed, so if you opened 2020 taxes you would get "WIN_FORM_PAGE_A317_2020" and if you opened 2019 or 2018... you get the idea.
It was a horror from the usual "software engineering practices" standpoint on stuff like code re-use, but it was super easy to do and based on the risk analysis it was the best/easiest/cheapest solution to be able to test, review, and ensure the accuracy of EVERY tax rule we implemented with iron-clad certainty.
Someone in QA would just go to each function, make sure it calculated things correctly based on the requirements, and do a few other checks. We had a big QA department that would do test driven development on each pull request (if it failed, you went back to fix it again, so since we used Visual Source Safe we ENSURED it worked the first time; you know what I mean if you used VSS) and sit down with the developer for each function and go through it in a heavy review. I can't imagine trying something like that in React or whatever, you could never ensure the software would always behave the same way each time with the network latency and huge underlying security concerns for the framework and a bunch of other issues we would have had to overcome to prove it worked correctly every time. Backend frameworks would be even WORSE for our risk profile.
Most importantly: no one cared what the damn UI looked like as long as all the buttons and text boxes were there in the designated configuration. They were all Windows 95-style UI boxes and I doubt that the front desk agents would have been happier to use some Reactified "pretty" stuff.
The story is just to say that I agree with you wholeheartedly that the UI/UX space has exploded with useless garbage you don't need in a simple, boring business tool and 95% of software is just that, simple and boring.