I have just wasted a week on various online form-filling exercises (banking, government, other stuff) and none of it works properly. Websites crash. Pages are missing or don’t display properly. Apps (eg., Captchas) fail for no apparent reason. Buttons can’t be pressed. Pages sit there for minutes at a time with that little wheely thing spinning round and then eventually time out with some stupid message. I have achieved virtually nothing.
More commonly I just can’t figure out how the system implements the thing I want to do, due to crappy UI design, pisspoor architecture, or because someone didn’t consider my use-case.
I’ve been exploring cryptocurrencies, and none of that works either, or works so imperfectly that nobody in their right mind would seriously consider using them as currencies.
Back in the day, when I was working on mainframes and coding in assembler, bugs were simply not acceptable. You didn’t just crank something out and say ‘that’ll do’, because it wouldn’t do. You’d get a fault-report form landing on your desk. We implemented some pretty complex tasks in a bare-bones fashion because we didn’t have enough RAM or CPU horsepower to bugger about with bells and whistles. And it all bloody worked.
So what’s going on in 2020? My theory: a plethora of ill-defined “application frameworks” and scripting languages, which are cobbled together by way too many people, are in a constant state of flux, and which employ millions of lines of code to do something utterly trivial.
Yeah, I’m bored (and annoyed). But it’s a serious question. What the hell is this all about? Are we destined to waste our lives away dealing with software errors?
Can’t stand Bob Dylan and his whiny voice, so this is entirely appropriate:
Don’t know what the deal is with captchas in particular, but for one of my bank accounts, I never get in with the first captcha. It always fails. And the second is always fine.
I think the cloud is a bit screwy at the moment with everyone working from home. I saw Azure demand up 775 percent, prioritisation rules in place on my feed this morning. I’m using AWS today and it seems ok though. Maybe the web pages you are using are Microsoft shops?
Yeah, I’m imagining toilet-paper production lines with state-of-the-art tablet-based production line monitoring, ERP software, blah blah … all with silly messages popping up every half hour: No network connection. Database error 0x5f13, please retry. Your system needs to update and restart. Installing update 18/474, please wait …
I dunno. I get the impression that blockchain itself is the problem. It demands huge amounts of processing power, storage, and network bandwidth (YMMV depending on the currency). This must inevitably translate to transaction inefficiency. It also seems to take anything from hours to days for transactions to propagate through the network. Ain’t nobody got time for that. The benchmark is cash or RFID card transactions, which take … ooh, 0.5 seconds to complete, with a guaranteed yes-or-no outcome. If crypto can’t meet that target, it’s a total waste of time.
Add to that the massive layer of regulatory crap that governments have dumped onto the crypto market, presumably with the explicit intent of making it more trouble than it’s worth. Not looking good, IMO.
Yep I see where you are coming from.
It’s not the only solution for payments, but there’s a lot more to it than payments, its ideal for automated accounting across borders for one. And for lending it is showing a lot of promise (but volatile as well because it is unregulated ).
The upgraded ethereum will help fix some of the issues.
Crypto systems can operate in a hybrid of cash and blochain finality transactions, similar to a credit card. Is it worth it to do that ? Agreed that’s an open question.
Yep it’s early days but I recommend you pick up a few ethereum for your trouble.
Anyone ever seen those puzzle captcha? It’s basically a picture and a piece of puzzle you are supposed to drag the piece to where it goes. At first I could never figure out how to do them because I thought you just drag the puzzle piece itself, but it turns out there’s a slider under the picture and that’s how you are supposed to solve it.
Imagine joining an engineering team. You’re excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he’s involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don’t worry, says Mary, Fred’s going to handle the walkways. What walkways? Well Fred made a good case for walkways and they’re going to add to the bridge’s appeal. Of course, they’ll have to be built without railings, because there’s a strict no railings rule enforced by Phil, who’s not an engineer. Nobody’s sure what Phil does, but it’s definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you’ll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it’s become a case of “whoever got to that part of the design first.” This has been such a headache for the people actually screwing things together, they’ve given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. After the introductions are made, you are invited to come up with some new ideas, but you don’t have any because you’re a propulsion engineer and don’t know anything about bridges.
Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.
lol. Typical ill-informed rant coming from 1-st generation computer “specialists”. FYI: you’re wrong on every point.
“back in the day” when you wrote in assembly (just as we millenials still do, when required), you had a very small code footprint due to system constraints. The system the size of a room could do what can be done in a 1x1 sq. micron chip can do today. Complexity increases, bugs increase - that’s a natural correlation. There’s nothing “lazy” or “poor” about that.
Today, your “fault-report form” is called buganizer or git issues. No-one just cranks something up saying it’ll do. 1000s of tests are run in multiple testing environments to ensure correctness. Does that still result it some bugs? Sure - but that’s not due to bad design. It’s a mathematical probability due to the inherent complexity in computer science.
Does that mean every piece of code written today is great? Ofcourse not. Just as it wasn’t 50 years ago. Is every chip rolling out bug-free? no…just as it wasn’t 50 years ago.
" This made the development of OS/360 and other System/360 software one of the largest software projects anyone had attempted, and IBM soon ran into trouble, with huge time and cost overruns and large numbers of bugs" - the book by Tannenbaum discusses it in more detail.
If you want to learn about test coverage and bugs, I suggest reading this paper:
https://hal.inria.fr/hal-01653728/document
“Designing test cases for the sole purpose of
increasing coverage may or may not translate to higher bug
finding rate” - and that is the fundamental problem. It is just not possible to think about every case beforehand. Today, our smartphones, are receiving radio signals, decoding them, while showing you a HD video, processing incoming notifications, triggering local timing events, sensing phone orientation - all in the palm of your hand. Try doing that with a mainframe and come bank to me with 0 bugs and the claim that “it just works”.
I do acknowledge some of the problems you’ve mentioned about UI design - but that boils down to bad mid- and upper- level management. If you don’t have a culture of paying attention to details, you will write sloppy code. That is not a tech-systematic problem - it’s a management and cultural one. In my own experience, most Taiwan system engineers cannot think about good software design. Maybe it’s a combination of poor English skills, stress on memorization, etc. Most of the young local engineers in my firm have only 1 mindset - sit at the desk for 12 hours a day to show you’re working hard. No think OOTB, no originality, no innovation. It’s very different in hardware - TSMC chips have amazing yield and efficiency for cutting edge < 10nm or beyond Silicon technologies - because they have amazing management which ensures that.
This is a nice article which tries to explain some of the reasons why the Japanese just cannot write good software:
Though it was written 30 years, ago, much of the points are still relevant, in some way, to today’s Taiwan.
