Live data from Hacker News

The Software Crisis

wryl.tech

81–90 of 201 posts

Re: The Software Crisis

#81

Shallow and composable is something we all experience when using UNIX tooling. GUIs are where this all falls apart as they are literal islands that don’t communicate with each other in a composable manner. I’ve been experimenting with some GUI-meets-shell-pipeline ideas with a tool I’ve been working on call guish. https://github.com/williamcotton/guish I’m curious to know if anyone knows of any similar tools or appro…

Yes, shallow, wide, and composable. That's how our abstractions should be.

But the larger problem is not GUIs. GUIs are a problem, but they are necessarily at the top of the abstraction stack, so the problem doesn't compose any further. (What interestingly means they are so much of a problem that they aren't anymore.)

The elephant in the room nowadays are distributed systems.

Re: The Software Crisis

#82
post #28

Earlier quoted context omitted.

The problem isn't minimal abstraction but imperfect abstraction. Imperfect abstractions convince people to dig underneath the surface. Now you've lost the benefit of abstraction because they're thinking of two layers at once. So when people run explain on their SQL query, IMO you've broken the declarative abstraction.

Asking the SQL engine to explain the query doesn't mean the abstraction is broken or imperfect. It simply means the developer wants to understand how their query is being understood and, hopefully, optimized. This is essential when debugging why queries don't behave optimally, e.g. failure to use an index. Even with the perfect abstraction, people will need to dig beneath the surface. This is because every layer of c…

> It simply means the developer wants to understand how their query is being understood and, hopefully, optimized.

Or, in other words, the developer wants to break the abstraction.

If your definition of "perfect abstraction" doesn't include the developer never needing to look beneath the surface, I'd say it's a pretty bad one.

Re: The Software Crisis

#83
post #48
post #45

OT: anyone's got an idea why Firefox would not be able to display that page in reader mode (button in the URL bar not showing up)? For some reason, my eyes cannot cope with white text on black backgrounds, so I usually just go to reader mode in cases like this article. But here, this option does not exist, for some reason?

Thanks for the feedback regarding this, I've been trying to find a middle-ground between my authoring style (writing raw HTML with low overhead, instead of using a static site generator) and "portable readability". I have a feeling it's just me not annotating the markup correctly, which I am in the process of fixing and porting around!

Personally, I've found that adding 3 lines of javascript to make a style switcher leads to great results. (You know you can simply load a CSS file in javascript and apply it, in a single command?)

Re: The Software Crisis

#84
post #16

Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…

Well, I don't think many people would disagree about the crisis.

Personally, I'm anxious to see your proposal on "how".

Re: The Software Crisis

#85
post #79
post #71

Earlier quoted context omitted.

> I don't think we have a software crisis. Millions of programmers are able to create more or less useful programs all over the word; everything including your toaster is running software on it succesfully enough; and the community was able to build programs that are accessible to all from a 5 year old kid all the way to your grandparents. Where is the crisis in it? About that toaster point; this is the actual, real,…

But I wouldn't call a toaster running code an example of software crisis. Call it business crisis or crisis of capitalism/consumerism, but it is not software crisis. I agree wholeheartedly that an internet connected toaster is a very stupid idea, but our ability to build such a system shows, if anything, a triumph of software (and hardware), not a crisis. What is a crisis here is societal one; the fact that there is…

> I agree wholeheartedly that an internet connected toaster is a very stupid idea, but our ability to build such a system shows, if anything, a triumph of software (and hardware), not a crisis

We have managed to build systems with software that "triumph" for a very long time. Look no further than Voyager 1. A technical masterpiece which still works.

But fundamentally, about the toaster; we see these things in toasters because there are so many abstractions and possibilities. It is easy to embed software for the toaster without having a legion of software developers from different fields.

And it adds up and is the main issue of "unintended" usecases for toasters. Many from these cases are not depending from the developer. Developers do not even know about them or were not thinking about them because there were abstracted away. Overall system of the toaster can be so complex in these days, that no single person can understand it completely alone.

But yes, the consumer part and that it is okay if toaster breaks, is indeed social problem. But likelihood of toasters breaking or doing something else than supposed to, could be originating or increasing from the software crisis.

Re: The Software Crisis

#86

Earlier quoted context omitted.

The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality. With a bridge, for example, at some level it must meet a minimum bar of structural integrity, quality of materials, etc. or it will fall over from its own weight. As a cook, there is a bare minimum I have to hit with the quality of my ingredients and skill of preparation in order…

> 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 m…

> 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.

Re: The Software Crisis

#87

If you look at the resumes of engineering or automotive company leadership, you'll see people going through stages of ever expanding responsibilities of part, component and product design, or management of production facilities of increasing size and importance. The CEO will still emphasize their technical knowledge, non-technical staff will at least try and fake it. In agile software development on the other hand, t…

Counterpoint: Boeing.

Re: The Software Crisis

#88

This article presupposes that this software crisis actually exists or is a significant problem. The crisis is all this these things: Projects running over-budget Projects running over-time Software was very inefficient Software was of low quality Software often did not meet requirements Projects were unmanageable and code difficult to maintain Software was never delivered Now take the word "software" out and how many…

> how many human endeavours have one or all of these things? You want a binary answer as in "it never happens with X"? Because for most kinds of project, we say it didn't go well when 1 or 2 of those happen, while we declare a victory in software if we manage to avoid 2 of them. > And then how much software is actually pretty great? And now I'm curious about your bar for "pretty great" software. This is obviously sub…

> This is obviously subjective, but most people wouldn't look at any practical software and call it great.

This what I think is insane. We interact with probably thousands of pieces of software every day (and I'm probably off by an order of magnitude) and none of it is great? What is the bar here?

It's funny that something that was absolutely amazing yesterday is no longer even so much as great today. I can instantly connect to a remote server from my phone, type some text, and generate a pretty good poem about my cat and all of that is already "meh".

Re: The Software Crisis

#89

Earlier quoted context omitted.

> 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 m…

> 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 k…

I think I agree with you but disagree with the article.

> 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.

There is way more software out there than one can even imagine responsible for literally every aspect of human society. There is an insatiable need for more software and there simply isn't enough software developers in the world to do it all. What you get is triage -- things half baked because of effort. There isn't some problem specific to software with regards to physical constraints. Cheap stuff made quickly breaks whether it's software or power tools or children's toys. It's that simple.

> And that was because Steve Jobs was the forcing function on quality.

Exactly. What does that have to do with abstractions or the lack of physical constraints?

Re: The Software Crisis

#90
post #28

Earlier quoted context omitted.

Asking the SQL engine to explain the query doesn't mean the abstraction is broken or imperfect. It simply means the developer wants to understand how their query is being understood and, hopefully, optimized. This is essential when debugging why queries don't behave optimally, e.g. failure to use an index. Even with the perfect abstraction, people will need to dig beneath the surface. This is because every layer of c…

> It simply means the developer wants to understand how their query is being understood and, hopefully, optimized. Or, in other words, the developer wants to break the abstraction. If your definition of "perfect abstraction" doesn't include the developer never needing to look beneath the surface, I'd say it's a pretty bad one.

This one is interesting.

The abstraction for SQL is related to how the work gets done, not what it produces. The missing piece is for the user to be able to control that optimization of how the work gets done, which is getting right down into the details of what SQL was abstracting in the first place.

There could be a middle ground where the user provides input about target performance and the engine uses that input during choice of execution plans.

Maybe an OPTIMIZATION clause for difficult or long running queries: ALLOW_EXTENDED_PLAN_SEARCH=True or MINIMIZE_EXECUTION_TIME_FACTOR=10 (1=just do simple, 10=expend more time+space up front to reduce overall time)

Post reply on HN