4 ms·

> No, I'd argue it's much more common for there to be flaws. They're just not obvious. They're random crap like my phone continuing to vibrate after I've answer

> No, I'd argue it's much more common for there to be flaws. They're just not obvious. They're random crap like my phone continuing to vibrate after I've answered the call until I get another call or text. This is kind of what I'm talking about. The absolute massive complexity within your device that you and billions of people to seamlessly make calls from anywhere in the world to anywhere in the world with devices made by all different companies using infrastructure made by all different companies and it all works so incredibly well that we mostly take it entirely for granted. But yes, sometimes the phone doesn't stop vibrating.

adamrezich 2y ago
One big difference between software and everything else is that software is built on top of other software, on top of other software, in an ever-increasing stack of abstractions and "good enough". This stack grows faster in software than in any other domain, because, as jdbernard said above, there's a lack of physical constraints preventing this from occurring. As this stack grows and grows, more points of failure are introduced, which can cause emergent, unexpected bugs and issues, which are hard to diagnose and pin down, because doing so involves traversing the stack to find the root cause(s). It's one thing to appreciate the natural world around us and how it all seems to work together flawlessly to provide the reality we all experience together—but that's because it's natural, not artificial, like the world of software we have created. When things work less than perfectly in software, there are human causes behind it, which, once identified, could be resolved in order to improve everyone's lives. But instead, most people share your "good enough—it's a miracle it all works!" mentality, which causes acceptance of any and all software issues, which leads to further issues down the line as we say "good enough" and build yet another layer atop it.
- wvenable 2y ago
  What I've noticed is that most issues are at the leaves. Abstractions that have existed for a long time and that are used heavily tend towards being more solid over time. (And more documented, well known, etc) It's the stuff at the edges that appears to be less reliable but that's mostly because it's new. It doesn't really feel like that is getting worse though. We are constantly interacting with more and more software than ever before but it's not like everything is broken. The fact that you can reliably make a phone call is far more significant than the fact that the vibration doesn't stop. Both are build on ever-increasing stacks of abstractions. The difference in that example isn't some emergent complexity -- it's just that one is more important than the other. There are lots of analogies in the physical world where less-important things are crappier than more important things. We don't consider that some crisis of abstraction.
- danielovichdk 2y ago
  This to me is a cliché that laments the fact around how certain aspects and communities in software is very popculcural. One thing good programmers do well is choosing abstractions that are tested and validated, not popular or hyped. The stack has not changed I decades. E.g It's still TCP, memory allocations and perhaps SQL. Whether you don't want to learn those is up to you. Learn them and you will know your way around for decades to come.
jdbernard 2y ago
> But yes, sometimes the phone doesn't stop vibrating. I failed to communicate clearly. Yes, I agree, the scope of human achievement is amazing, software included. However, the issues with software go far deeper than just the trivial example I gave of the phone. It's pervasive and pernicious. I assume most software developers understand this as lived experience, but I'll elaborate more. Almost every single person I know who is not an IT professional of some sort regularly comes to me, my son, and others who are IT professionals for help with things that are broken and non-functional to the point that they cannot use it without assistance. And that's just the show-stoppers. There is tons of crappy software that they've just found workarounds for, and they've gotten so used to having to find workarounds that they've just stopped complaining. Not because it's working correctly, but they would rather be happy and accept it than get constantly worked up about something over which they have no control. This is not entirely unique to software, but there isn't really any other mass technology that is as bad as software. Software is simultaneously miraculous and horrible. Because of computing we have capabilities that would be seen as science fiction or magic not too long ago. But because of the things called out in this article, these magical tools and technologies are plagued by endless amounts of things that just don't work right, break randomly, and fail in unexpected ways. With physical systems and hard sciences we identify the physical constraints, model the system, and then engineer solutions around those models, refining our solutions as we refine our models. With software we make up the models, rarely fully document them, and slap things together as we go. Some companies do better than others, and some domains take quality and reliability seriously, but in my experience even that correlates to distance from physical constraints. In general the portions of our industry that are closer to real-world constraints (chip manufacturing, control interfaces, etc.) have historically been better about delivering quality software. If I come across as frustrated it's because I am. I love building software, and I used to love using software, but I am incredibly frustrated by the gap between what we've built and what is possible. I could keep going, but I'll end this comment with one other observation. I'm not an Apple fanboy by any means, but Apple used to be the exception to this general rules of "software just kind of generally sucks." Apple used to be "it just works." And that was because Steve Jobs was the forcing function on quality. It's possible. Again, this isn't unique to software. Excellence in any domain requires someone to be the standard bearer. At a restaurant it may be the head chef, refusing to let anything out of the kitchen that doesn't meet their high bar, for example. In every domain there exist various pressures that push quality down (time, cost, etc.) but software lacks the natural floor established by physical constraints, and is unique riddled with problems, IMHO.

adamrezich 2y ago

One big difference between software and everything else is that software is built on top of other software, on top of other software, in an ever-increasing stack of abstractions and "good enough". This stack grows faster in software than in any other domain, because, as jdbernard said above, there's a lack of physical constraints preventing this from occurring. As this stack grows and grows, more points of failure are introduced, which can cause emergent, unexpected bugs and issues, which are hard to diagnose and pin down, because doing so involves traversing the stack to find the root cause(s). It's one thing to appreciate the natural world around us and how it all seems to work together flawlessly to provide the reality we all experience together—but that's because it's natural, not artificial, like the world of software we have created. When things work less than perfectly in software, there are human causes behind it, which, once identified, could be resolved in order to improve everyone's lives. But instead, most people share your "good enough—it's a miracle it all works!" mentality, which causes acceptance of any and all software issues, which leads to further issues down the line as we say "good enough" and build yet another layer atop it.

wvenable 2y ago
What I've noticed is that most issues are at the leaves. Abstractions that have existed for a long time and that are used heavily tend towards being more solid over time. (And more documented, well known, etc) It's the stuff at the edges that appears to be less reliable but that's mostly because it's new. It doesn't really feel like that is getting worse though. We are constantly interacting with more and more software than ever before but it's not like everything is broken. The fact that you can reliably make a phone call is far more significant than the fact that the vibration doesn't stop. Both are build on ever-increasing stacks of abstractions. The difference in that example isn't some emergent complexity -- it's just that one is more important than the other. There are lots of analogies in the physical world where less-important things are crappier than more important things. We don't consider that some crisis of abstraction.
danielovichdk 2y ago
This to me is a cliché that laments the fact around how certain aspects and communities in software is very popculcural. One thing good programmers do well is choosing abstractions that are tested and validated, not popular or hyped. The stack has not changed I decades. E.g It's still TCP, memory allocations and perhaps SQL. Whether you don't want to learn those is up to you. Learn them and you will know your way around for decades to come.

jdbernard 2y ago

> But yes, sometimes the phone doesn't stop vibrating. I failed to communicate clearly. Yes, I agree, the scope of human achievement is amazing, software included. However, the issues with software go far deeper than just the trivial example I gave of the phone. It's pervasive and pernicious. I assume most software developers understand this as lived experience, but I'll elaborate more. Almost every single person I know who is not an IT professional of some sort regularly comes to me, my son, and others who are IT professionals for help with things that are broken and non-functional to the point that they cannot use it without assistance. And that's just the show-stoppers. There is tons of crappy software that they've just found workarounds for, and they've gotten so used to having to find workarounds that they've just stopped complaining. Not because it's working correctly, but they would rather be happy and accept it than get constantly worked up about something over which they have no control. This is not entirely unique to software, but there isn't really any other mass technology that is as bad as software. Software is simultaneously miraculous and horrible. Because of computing we have capabilities that would be seen as science fiction or magic not too long ago. But because of the things called out in this article, these magical tools and technologies are plagued by endless amounts of things that just don't work right, break randomly, and fail in unexpected ways. With physical systems and hard sciences we identify the physical constraints, model the system, and then engineer solutions around those models, refining our solutions as we refine our models. With software we make up the models, rarely fully document them, and slap things together as we go. Some companies do better than others, and some domains take quality and reliability seriously, but in my experience even that correlates to distance from physical constraints. In general the portions of our industry that are closer to real-world constraints (chip manufacturing, control interfaces, etc.) have historically been better about delivering quality software. If I come across as frustrated it's because I am. I love building software, and I used to love using software, but I am incredibly frustrated by the gap between what we've built and what is possible. I could keep going, but I'll end this comment with one other observation. I'm not an Apple fanboy by any means, but Apple used to be the exception to this general rules of "software just kind of generally sucks." Apple used to be "it just works." And that was because Steve Jobs was the forcing function on quality. It's possible. Again, this isn't unique to software. Excellence in any domain requires someone to be the standard bearer. At a restaurant it may be the head chef, refusing to let anything out of the kitchen that doesn't meet their high bar, for example. In every domain there exist various pressures that push quality down (time, cost, etc.) but software lacks the natural floor established by physical constraints, and is unique riddled with problems, IMHO.