Submitted via IRC for Bytram
This week Samuel Arbesman, a complexity scientist and writer, will publish "Overcomplicated: Technology at the Limits of Comprehension." It's a well-developed guide for dealing with technologies that elude our full understanding. In his book, Arbesman writes we're entering the entanglement age, a phrase coined by Danny Hillis, "in which we are building systems that can't be grasped in their totality or held in the mind of a single person." In the case of driverless cars, machine learning systems build their own algorithms to teach themselves — and in the process become too complex to reverse engineer.
And it's not just software that's become unknowable to individual experts, says Arbesman.
Machines like particle accelerators and Boeing airplanes have millions of individual parts and miles of internal wiring. Even a technology like the U.S. Constitution, which began as an elegantly simple operating system, has grown to include a collection of federal laws "22 million words long with 80,000 connections between one section and another."
In the face of increasing complexity, experts are ever more likely to be taken by surprise when systems behave in unpredictable and unexpected ways.
Source: http://singularityhub.com/2016/07/17/the-world-will-soon-depend-on-technology-no-one-understands/
For a collection of over three decades of these (among other things) see The Risks Digest - Forum On Risks To The Public In Computers And Related Systems. It's not so much that this is a new problem, as it is an increasingly common one as technology becomes ever more complicated.
(Score: 5, Insightful) by takyon on Wednesday July 20 2016, @05:32PM
If you can't understand the machines, you will end up worshiping them instead.
Time to post some quantum computing articles.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 1, Touché) by Anonymous Coward on Wednesday July 20 2016, @05:33PM
On some level, a screwdriver is more complicated than any person can possibly comprehend. All those atoms connected via electron bridges, etc.
But I look forward to buying your next Singularity(tm) book. Do you have a newsletter?
(Score: 2) by JoeMerchant on Wednesday July 20 2016, @10:27PM
I wasn't going to go the atomic route, but rather the complexity of nature: never knowing when the volcano will erupt, drought will break, herd of wildebeest will come charging through. As a species, we've been dealing with systems of unknowable complexity and depth since we first learned to talk with each other enough to realize that we just don't know everything we don't know.
The difference now is that these are systems virtually entirely of our own making, made of well defined components that we do understand, not built up from a natural world with components that we don't fully understand.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Informative) by frojack on Thursday July 21 2016, @01:24AM
Neither atoms or volcanoes are pertinent here, because we don't built them, and don't have to maintain them.
We no longer hold any system to a standard of being held in the mind of a single person, and we haven't done that since we crawled out of the cave.
We've practiced a division of labor, and a division of memories. You remember where and when to get the best berries and roots, I'll remember where the rabbits are at any given time of the year.
As we become more people, our total capacity to remember grows. So we fill our individual heads and knowledge grows.
And things that need remembering, (because they need constant attention) are eventually fixed so as not to require attention, or have extensive manuals documenting it all. And the lack of a manual combined with nobody remembering how it works usually means that part gets replaced with a newer model.
Yes, with a few years of inattention, such as after a large meteor strike followed by a couple years of dust winter, there are some things that will fall to disuse, or disrepair, for which parts and technicians are not available. Probably won't be our cars and planes and computers, because these require constant attention, and there are a lot of people knowledgeable in these areas.
Guessing what will fall to disrepair and forgetfulness is the genera of a million distopian novels, but even these probably over sell the case.
The situation is a lot less dire than the breathless article would lead you to believe.
A single mind was never the standard.
No, you are mistaken. I've always had this sig.
(Score: 2) by JoeMerchant on Thursday July 21 2016, @03:13AM
My favorite illustration of documentation was the last nuclear submarine to be built with a paper based documentation system - the paper outweighed the sub. We've since paperless, and if you were to print the paperless documentation, it's orders of magnitude larger than the paper documentation it replaces - EULAs are but one example of text proliferation in the realm of zero delivery cost per page.
Normally, I don't like taxes, but I think a return of a documentary stamp tax would be a good thing. Any agreement that is "legally binding" must pay a tax of $0.01 per 100 words (1000 characters) in order for it to be considered legally binding, whether physically signed, e-signed or click-wrap clicked to agree. Adjust that tax (probably upwards) until agreements start shrinking back to something reasonable. You used to be able to contract for sale and purchase of a home in 6 or so pages, today it's usually upwards of 20, and that's all about the e-sign. There's no more valuable information in the contracts, mostly a lot of repetition and even copy-paste of whole pages, and of course obfuscation of some of the important things under mounds of stuff that really doesn't matter.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by Adamsjas on Thursday July 21 2016, @06:59AM
I think the valuable information is still there, and the people who care, namely the buyer and seller know exactly what matters. The rest is there to protect the lawyers and innocent bystanders.
(Score: 2) by JoeMerchant on Thursday July 21 2016, @08:57PM
The lawyers need to go on a diet.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 0) by Anonymous Coward on Thursday July 21 2016, @09:13AM
Also, humanity depended on the fire since the stone age. But only in modern times we learned to understand it.
(Score: 4, Informative) by Rosco P. Coltrane on Wednesday July 20 2016, @05:42PM
Most people in the 18th century didn't understand how a Jacquard loom worked either. That didn't prevent them form using them, and wearing clothes made with them.
The only difference today is that even the best brains can't fully grasp how a complex computer system works. But I suspect it isn't new either: ever since compilers have gotten better at optimization than humans, it's become more or less impossible to understand fully the ins and outs of a complex piece of computer software.
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @05:52PM
People keep saying that compilers are better than humans ... I'm not sure if I fully believe that ...
(Score: 1, Interesting) by Anonymous Coward on Wednesday July 20 2016, @06:47PM
>People keep saying that compilers are better than humans ... I'm not sure if I fully believe that ...
Compilers obviously are much better than the persons singing their praise. :) Because not noticing how bad compilers really are at optimizing, requires quite an advanced level of stupid.
I routinely can speed up code anywhere from 30% and up to 300% just by looking at assembly output and tweaking the C source, without resorting to writing assembly myself. Which means, I only make compiler avoid its most glaringly idiotic choices, while still leaving all the smaller inefficiencies be; there remains a whole lot of cruft to be cut out with a clean assembly rewrite, if I ever needed that last bit of performance at the cost of portability.
Compilers are lame, but many coders out there are lamer. :)
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @06:54PM
Could you list the compilers you've found to produce inefficient code?
Just curious, as I have no doubt that compilers can differ.
Also, what optimization settings did you use?
(Score: 2) by Scruffy Beard 2 on Wednesday July 20 2016, @07:20PM
Probably using the Intel compiler for AMD hardware. :P
I suspect The GP may be alluding to unrolling loops enough to allow the CPU to execute 4 instructions per clock cycle.
(Score: 2) by bzipitidoo on Wednesday July 20 2016, @07:49PM
Lot more than that. Just look at the assembler a compiler produces, you'll see all kinds of things. Stuff like this:
loop:
(bunch of assembler)
dec r1
bnz loop
load r1,0
Uh, compiler, r1 is already 0 upon exiting that loop, it was not necessary to load 0 into r1. Oh, and if you insist on zeroing out r1 anyway, why did you do it with a load command instead of xor r1,r1? Was it that you didn't want to change any flag settings? No, the next few instructions don't need any leftover flag settings, which in any case were unchanged from the way the decrement command set them.
As to the subject of the article, compilers are NOT complicated beyond our understanding. Careful not to extrapolate the mere condition of being hidden, hard to view, to being impossible to understand.
(Score: 2) by Arik on Wednesday July 20 2016, @08:44PM
Because the compiler is essentially pasting in a function, and that function is (as it should be) written to be as generic and bulletproof as possible. This is how it has to be done, and this is why even the platonic ideal compiler, with perfectly written functions and no bugs at all can still be beaten by a human at this.*
"As to the subject of the article, compilers are NOT complicated beyond our understanding."
Perhaps compilers are not but modern 'desktop' computers may well be. The software stack typically present has grown so huge and bloated, and it's so messy in design and implementation, I really don't think any single person understands any of the modern examples.
*but note that this assumes the human has skills and is given a lot more time than the compiler will use.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by bzipitidoo on Wednesday July 20 2016, @10:51PM
> The software stack typically present has grown so huge and bloated, and it's so messy in design and implementation, I really don't think any single person understands any of the modern examples.
Oh, bull. If we are talking about formal verification to prove that the software functions correctly and has no bugs, you're right, it's far too big and complicated for that. But we're not. We have a crucial, core tool in software engineering, modularization.
This reminds me of a debate I heard over control systems at a heating, ventilation, and air conditioning (HVAC) company. The traditional way was to have one diagram per possible configuration. When there were only a few models of thermostats, furnaces and A/C's, that was possible. But when the numbers ballooned, they began to panic. 100 thermostats, 50 different models of furnaces, and 50 different models of A/Cs meant drawing 100x50x50 = 250,000 diagrams, something they simply did not have the resources to do. Add in yet another device, for ventilation only, and that number grew to well over 1 million. For a while they managed by only creating diagrams on demand, wouldn't make one for a configuration unless at least one customer actually used it. But the ultimate solution was modularity. Instead of 100x50x50 diagrams, they needed only 100+50+50 = 200 diagrams. Each thermostat, furnace, and A/C had its own diagram, and whichever ones were wanted in a complete system could be connected together. Years after this was in place, a new batch of engineers who didn't know about the system fell into the same mistake, and began to panic over having to create millions of diagrams. But that time, computers had become ubiquitous, and they proposed writing programs to generate all those millions of diagrams, and hiring software engineers to handle that. Their plans didn't go far before they learned they were being silly. Quite a few red faces over that. As the famous saying from Hitchhiker's Guide to the Galaxy goes, "Don't panic".
(Score: 2) by sjames on Wednesday July 20 2016, @10:24PM
Did you forget to pass it -O3 permitting it to elide instructions?
(Score: 2) by bzipitidoo on Thursday July 21 2016, @12:32AM
I admit I haven't kept up with what compilers can do. I know -O3 was added quite a few years ago. And I know register juggling has gotten very sophisticated. As I recall, optimal register assignment is an NP-hard problem, but there are few enough registers and fast enough computers now that the compiler can employ an exponential algorithm to find the optimal solution without making compilation unacceptably slow. How far optimization goes now or will go in the near future, I don't know, all the way to -O6?
(Score: 2) by sjames on Thursday July 21 2016, @01:20AM
We're up to -O6 (or perhaps more by now), but it's not standard and it may take unsafe liberties with floating point.
(Score: 1, Touché) by Anonymous Coward on Thursday July 21 2016, @09:16AM
Optimization will not be good enough until it goes to eleven!
(Score: 2) by hendrikboom on Thursday July 21 2016, @05:47PM
Compilers got to be better than humans sometime in the 70's. Not that all of them are, nor even that humans can't improve a lot of fragments of the code they generate. But when you start to look at programs of thousands of lines of assembler, people get tired, and fail to work on each fragment at their human peak optimization ability.
Compilers may do worse in small pieces of code, but they don't get tired and in the long stretches they end up excelling. It's like the difference between a sprinter and a long-distance runner.
Hand-optimizing the few bits of code that are time-critical can, of course, still improve efficiency.
Not to mention that coding a lot of assembler can blind you to the possibilities of changing data representations or algorithms, which I'm not even taking into account.
But I'll agree that on small pieces of code, like the ones presented in this discussion, human programmers can often outdo compilers.
(Score: 2) by Arik on Wednesday July 20 2016, @08:35PM
But also, remember a compiler is just a computer program, so of course what's true of computer programs in general is true of it. It can do many common tasks MUCH faster than any human would ever manage. But it can't truly think, so of course they will still inevitably miss a ton of stuff that someone who truly codes (i.e. someone that can read a hex dump at a glance) will be able to bring to the table.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by Ethanol-fueled on Wednesday July 20 2016, @06:09PM
Documentation, documentation, documentation. In both technical and layman's terms.
This is something that "smarterer" people have always sucked at, either because they're Aspies or because they want to make themselves more valuable in making understanding difficult for others.
Or in the case where we can't blame individuals but the academic and professional climates, which encourage short-term gain (where documentation is considered a time-consuming chore) over long-term benefit to all.
Of course no one man is going to completely understand a complex computer architecture at the transistor level. You build shit like that, like you build anything large and complex - incrementally, using a variety of specialists, (hopefully) testing and verifying each integration step as they go.
(Score: 2) by Nerdfest on Wednesday July 20 2016, @08:23PM
Even "experts" at certain things get overwhelmed by complexity. Software is an example, but law is another one. The example given of the constitution is a good one, and the solution should be the same as an overly complex software system: refactor it. Extract the intention ... ideally it should be clear. If the intention is not clear, work it out and word it so it *is* clear.
As for software, there was a William Gibson book (All Tomorrows Parties maybe?) where people searched out old bits of firmware for their code as it was still embedded in lots of other system and could be exploited.
As with hardware, software, end even documentation describing complex processes needs to be *maintained*. It never gets simpler on its own, and eventually, it will bite you.
(Score: 2) by frojack on Thursday July 21 2016, @01:33AM
This is why its a good idea to toss the whole damn thing out and do something different once every few generations.
Just when you thought you could master the internal combustion engine, they started computerizing what use to be done mechanically.
Then along comes Tesla. Fully electric cars are orders of magnitude more simple than a modern ICE.
We could start by throwing Germans out of software development. I say this with tongue lodged firmly in cheek, but jeezus those guys will add three layers of indirection from the time you get up to fill your coffee cup till you sit back down. One config file gets broken out into 3 sub-directories full of little files all included or excluded by some script which is equally scattered to the four corners of the hard disk. Germans: Please stop!!!
No, you are mistaken. I've always had this sig.
(Score: 2) by bob_super on Wednesday July 20 2016, @05:43PM
If you want to get away with the occasional bugs in a system you heavily profit from, just claim that it's way too complex for even its creators to understand.
Don't forget to claim your billions when it fails.
(Score: 2, Insightful) by TheSouthernDandy on Wednesday July 20 2016, @06:01PM
"in which we are building systems that can't be grasped in their totality or held in the mind of a single person."
Anyone carrying a wiring diagram for a Boeing 787 in their head? Anyone?
I suspect the intended meaning of the quote is being taken out of context by the OP, but these singularity folks are primarily hucksters, IMHO.
That said, everything is too damn complicated now. I just changed a login password, and have been locked out of our entire network ~10 times because too many partially connected systems rely on the same password, but do not automatically update from a single interface, and N failed attempts results in auto-lockout.
(Score: 2) by krishnoid on Wednesday July 20 2016, @07:24PM
Anyone carrying a wiring diagram for a Boeing 787 in their head? Anyone?
Depends -- is it under 80GB?
(Score: 2) by RamiK on Wednesday July 20 2016, @07:39PM
I'll ask Dr. Allcome.
compiling...
(Score: 0) by Anonymous Coward on Thursday July 21 2016, @01:09PM
i got a dolphine for sell.
i can ship via boeing 787 ...
(Score: 3, Funny) by bob_super on Wednesday July 20 2016, @07:39PM
> Anyone carrying a wiring diagram for a Boeing 787 in their head? Anyone?
I'm sure spy recruiters are really happy that microSD cards can now fit all the target's data. Hiding 8-inch floppies in your mouth was a skill that paid better in SoCal than in the KGB...
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @09:38PM
The clue is "complexity scientist". Sounds just as bad as those who bill themselves as "futurists".
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @06:03PM
"Too complicated" means "No Docs".
A 747 with millions of parts is no too complicated, because Boeing supplies millions of doc to help understand, maintain and repair it. If something is missing, they are there to help. If it falls from the sky, they are there to pickup the pieces and figure out how it happened and to update the machine and the doc to prevent it from happening again.
It is us that makes thing "too complicated" - we waste hours of work on build systems in multiple languages, when one will do. To prove that only we can maintain it.
(Score: 4, Interesting) by JNCF on Wednesday July 20 2016, @06:27PM
But even with docs, a single human can't understand it all. I think TFA is correct about this, I just don't think it's very important. Anybody who has created a system too complex for themselves to remember every detail of without looking at docs/diagrams/code is aware of this. You're necessarily working in a mental fog after a certain level of complexity, even if you can grasp every detail one at a time. I think organizations are the same way. Groups of people can tackle a problem in small pieces and stitch those pieces together. It's not important that an individual human can't work through the mental fog of a 747, because Boeing can. Nobody ever expected a single human to understand a 747, nor did we expect a single human to build an aqueduct. Some tasks have to be done by groups, or we can't have nice things.
The point about machines designing systems too complex for any group of humans to understand is more interesting to me.
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @07:31PM
you are just quitting before beginning. It is "too hard". I get that from my kids with math problems. Break it down and get going.
747 is easy to get your head around it. It is plane (flys in the air), it is made of a tube, with 2 sets of wings one mainly for lift and the other guidance. What if Lift? Physic problem. and so and so on and so on. It is all frames of reference.
Thing of the Skunk Works on the late 04's and 50's... U2, SR-71 built with slide rulers and few people. Trip to moon again, built in stages a scaled up.
It is up to each of to do the right job, not A job.
(Score: 1, Insightful) by Anonymous Coward on Wednesday July 20 2016, @07:37PM
Sounds like Mr. Arbesman is learning why we have APIs. As long as foo(bar) properly foos the bars I pass it, I don't need to know how it works and there's no way I could keep in my head how all the APIs I call actually work.
(Score: 1, Touché) by Anonymous Coward on Thursday July 21 2016, @09:29AM
Depends on what you mean with "understand it all". Strictly speaking, it is impossible to understand even a simple fire. There are just too many ways it can burn.
If you think "understanding" means "knowing every detail" you don't understand what understanding means. The essential part of understanding something is to know when a detail does not matter.
(Score: 2) by JNCF on Thursday July 21 2016, @03:17PM
I agree with this. I do think you can understand some systems completely at a certain level, and I was trying to discuss systems where this is not the case. My language could have been more precise. I considered clarifying it, but cut a paragraph for brevity.
Of course, all of our systems are emergent phenomenon running on top of a universe we don't understand. Computers work well enough that we can mostly abstract the lower levels we're running on top of. This doesn't always work, and once in a while background radiation flips a bit or a truck drives into a computer while it's operating. It is the leakiness of our abstractions that allows this, and may always allow it with some probability. I see this as a different issue than not understanding the level you're working on, even though that's an arbitrary division made by my human brain. Fizz-buzz programs are simple enough that you can correctly model their output if we assume that lower levels work as expected, but larger programs that use more data than you can juggle in your working memory don't have this property. You can abstract this data behind interfaces, but it's still part of the system that runs at the same level. I believe we're on the same page, but correct me if I'm wrong.
(Score: 2) by Bot on Wednesday July 20 2016, @08:28PM
>build systems in multiple languages, when one will do
LINGVA LATINA PRO VICTORIA
oh sry, you meant
JAVASCRIPT
Account abandoned.
(Score: 4, Insightful) by SecurityGuy on Wednesday July 20 2016, @06:22PM
There seems to be a false premise at play, namely that it's important that we not have things that are more complicated than can be held in the mind of a single person. The fact that we're building ever more complicated systems of things that work really well would seem to disprove that premise.
As for "a collection of federal laws "22 million words long with 80,000 connections between one section and another."", yes, there's a difference between useful complexity and excessive complexity.
(Score: 3, Insightful) by VLM on Wednesday July 20 2016, @08:28PM
The fact that we're building ever more complicated systems of things that work really well
Not really, no. We can trade off higher tech to patch over stuff, and play expensive games with abstraction but there are limits.
Its a simple systems engineering problem. It almost echos of Shannon's Law relating an information rate (ditto), a bandwidth (tech level?), and power to noise ratio. (lines of code vs bug rate?)
There's been a lot of work done in reliability engineering.
Going a different direction, people who've never taken formal theory of computing classes tend to have really weird and unfortunately completely wrong intuitive ideas about simple scalability issues or halting problem related questions or what boils down to Godel's little problem.
If you're bored you can emulate a ram to CPU interconnect as a telecommunications bit stream, then play all kinds of weird games WRT bit error rates and power and noise. It turns out that even if you could build an infinite amount of infinitely fast ram, there are Shannons Law limits to how much fun you can have with that theoretically infinite processor. And since an ALU latch is just another transmission line etc etc etc.
(Score: 0) by Anonymous Coward on Thursday July 21 2016, @01:28PM
maybe it's about not allowing systems to fly thru the "too-complex" barrier so that they become a system upon itself.
if you want something to "not change" then you can make it complex so that other people cannot find a flaw or understand the intention of the system so as to be able to find a simpler solution.
also there's the danger that complex systems become irreplaceable and that humans need to be educated from early age to have enough time to grasp it by the time they are mature to add or rather maintain it. this is then a very complex system that can define a whole society, culture and maybe even language?
it is financially NOT interesting to keep systems simple and to the point?
it can also give rise to the notion of "heretics": this is the way it is done and no other way is tolerated.
in anyway, if planning to seriously go to outerspace for more then a dick-measuring plant-the-flag mission then humankind will be faced with a much more complex : ) problem then rocket-engine design: maintainability, replace-ability, repair-ability and easy resourcing of new components.
it will border on a manhatten project squared.
it will be like reinventing DNA but for spaceships and habitats.
maybe when meeting aliens, their stuff will integrate flawless because: universal space-technology DNA :)
(Score: 0) by Anonymous Coward on Wednesday July 27 2016, @07:57PM
The premise of "holding things in a single mind" is essentially the distinction between Engineering and Systems Engineering.
In a similar way, a distinction can be made between Programming in the Small and Programming in the Large.
(Score: 0) by Anonymous Coward on Wednesday July 20 2016, @06:24PM
n which we are building systems that can't be grasped in their totality or held in the mind of a single person
We've been there for a long while already... "Complexity is complex... news at eleven"
But then again, this idiot calls himself a "complexity scientist", so at least he's got that going for himself.
NEXT!!!
(Score: 2) by donkeyhotay on Wednesday July 20 2016, @07:04PM
Even with things as simple as toilets.
I helped a friend fix a toilet this weekend. She tried to do it herself, but the useful idiot at the DIY store sold her a new filler valve (which was NOT what she needed), and not only that, but the most expensive and complicated one in the store. The filler valve was so complicated, she could not get it to work. All she needed was a new flapper -- a $3 item. We put the stupid valve back into the box, and went back to the store and returned it. We got a flapper and a new filler valve that was about 1/3 the cost of the first one (unfortunately she had damaged the old valve trying to remove it). I showed her how to fix it, and she had a working toilet with only a few minutes of effort.
And the question is, why was this filler valve so complex? It was billed as "preventing leaks", but in operation, it was actually allowing the float to stay stuck in the down position which GUARANTEES a leak. A big messy EXPENSIVE leak. What engineer would design such a complicated stupid thing? All it needs is a simple, uncomplicated float, that will shut off the water when it gets to the correct height. We're all getting so sharp, we're cutting ourselves.
(Score: 3, Interesting) by JNCF on Wednesday July 20 2016, @07:40PM
Of course, a float will get caught on the chain more often than a filler valve will. For some tanks this only happens with an improperly adjusted (or plastic) chain, but others position the handle and the flapper so that the float can't be angled out of the way while keeping the chain short enough to do its job and the metal rod holding the float long enough to fill the tank properly. For such a poorly designed tank, the unobtrusive filler valve is a god send.
Even for tanks where this isn't an issue I buy the most pervasive brand of filler valves now (Fluid MasterTM) because I appreciate being able to replace the top half of them without disconnecting the bottom half, and I know I can get a new one anywhere. Hugging toilets is not fun, and neither is draining that last less-than-half-inch of water out of tank. The water is more-or-less clean, but the area around it that gets redampened by any water that runs down the bottom of the tank to outside of the bowl isn't.
But enough about toilets, the topic is bullshit!
(Score: 0) by Anonymous Coward on Thursday July 21 2016, @02:04AM
You simply disposed of their shitty solution b/c they didn't give you a shit disposal solution.
(Score: 5, Insightful) by SomeGuy on Wednesday July 20 2016, @07:06PM
This is hardly surprising. Every day businesses depend on software that is a loose hodge-podge that resembles a Rube Goldberg contraption. And they see no value in keeping anyone on staff to refactor or improve things because things "work". When things break or changes are needed they just work around it (often extending the Rube Goldberg-nes) until it becomes life and death critical. Then they get Habib in India on the phone to re-write the entire thing in [inapplicable buzzword of the day] which of course fails because no one even understands their own business logic more or less the existing code.
Sometimes that is acceptable - like your little doodad gadgets for posting to Facefook and Twatter and making phone calls. If a stupid little app breaks, who cares? But I think I will pass on the self-driving cars.
(Score: 1) by khallow on Wednesday July 20 2016, @08:05PM
(Score: 0) by Anonymous Coward on Thursday July 21 2016, @04:43AM
Since when are the words on a paper considered technology?
(Score: 2) by Scruffy Beard 2 on Thursday July 21 2016, @07:37PM
Are you arguing that paper is not technology?
(Score: 2) by sjames on Thursday July 21 2016, @05:17AM
Many have rightly pointed out that there have been things like that for a long time, but that we have devised ways to cope.
A real example is American medical billing. Go ahead, present to any American hospital for a surgical procedure and just try to get a no-nonsense direct answer to the question: "What will it cost me?". It's apparently so complicated that they can't even work it out. They often can't even guess within an order of magnitude.
(Score: 1) by redneckmother on Thursday July 21 2016, @01:40PM
Another interesting read on this was written long ago, by Charles Perrow: Normal Accidents ISBN-13: 978-0691004129 .
Mas cerveza por favor.