Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Software Crisis

wryl.tech

Post reply on HN
Print view View original

91–100 of 201 posts

Re: The Software Crisis

#91

Post by marcellus23 »

pauleee wrote: post #66
kleiba wrote: 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?

They didn't use proper html syntax like , , etc.; only . With this it's not possible for the browser to know what is the content of the article.

It's possible, just more difficult. E.g., Safari reader mode works fine for this page.

Re: The Software Crisis

#92

Post by stackskipton »

fuzzy2 wrote: post #56
stackskipton wrote: post #36

Earlier quoted context omitted.

I think categorizing it as "Too dumb" is also doing disservice to many developers who are stuck in feature factories. After a while you realize business is happy with status quo so do your Jira tickets, take your paycheck and go home. My puny stock options are extremely unlikely to be impacted by my work output. My boss doesn't care about Tech Debt. Get this ticket done, get it done quick and move on. He figures he w…

Though my employer certainly could be categorized as a feature factory (individual software development), we kind of sell the opposite: Sustainable development producing software which can be changed easily. There's only direct monetary compensation. Hierarchies are flat. Like, too flat. I understand many do not have the energy to fight the status quo and some may not have the… eloquence to do so. I have worked very…

Problem is, generally only places not doing this are FAANG and we all can't work there. I've interviewed at two FAANG companies in my field (Ops Type) and went ok but didn't get hired. So apparently, I'm not good enough for FAANG so far. Also, they are losing their luster as well.

Now, whatever. It's a job that pays well. I'm making rich people richer but I'm not sure what I'm supposed to do differently. MBAs continue to strip mine everything and my country upcoming elections are between two people we should be saying "Sure grandpa" while they tell us stories in their nursing home.

If that makes me dumb, I'll take the label I guess. I try not to be but when I'm having to explain to Dev for 5th time to stop doing appsettings.json, I realize that my tilting at windmills isn't going to fix anything.

Also, this is a feature factory: https://www.productplan.com/glossary/feature-factory/

Re: The Software Crisis

#93

Post by stackskipton »

wryl wrote: post #37
psychoslave wrote: post #31

> Very rarely do these models reflect reality. > It's a nice coincidence when they do. > It's catastrophic when they don't. Well, generally, it’s not my experience. Most software out there is not critical. Many bloated crappy webapp might end up badly doing what user is expecting while sucking irrelevantly large amount of resources all day through with erratic bugs showing here and there, yes all true. But this is no…

While I sympathize that the stakes don't appear to match up, I am talking about all software, and also taking into account the fact that these frustrations are numerous. It'd be one thing if it was taken in small pieces, small cracks in the stairs, but half of them are missing on average. I really don't like missing stairs. We're very removed from the usage of our software, and experience it in short-form (hopefully)…

I don't think most programmers are removed of usage of software. I have to use Google Workspace daily and I'm not sure how Workspace team doesn't have entire GooglePlex hunting for their head. Likewise, I'm shocked that Microsoft Teams is not secluded for their own protection. I've got a laundry list for Azure Team and most of Microsoft employees I know have same list yet it remains so some outside force is driving this.

However, I think it's clear why it's this. Business team wants cheaper developers and hope is that if you put enough abstractions out, they can turn over Development to AI or monkeys with typewriters trying to create great works of Shakespeare. I remember reading Log4J exploit and wondered which Log4J developer thought it was a great idea to allow "feature" they added in the first place. Probably someone trying to prevent the monkey from destroying the typewriter.

However, it's excellent article and I await the next installment.

Re: The Software Crisis

#94

Post by joe_the_user »

wryl wrote: 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…

I liked the way you showed the problem as ongoing in history. Indeed, the phrase "software crisis" is nice because it references the first point when the situation was articulated.

That said, I think the reason the situation is not going to change is clearly economic. That's not saying that bad software is cheaper. But there's a strong incentive to cheap, bad practices because cutting corners allows one person/organization to save money now with the (greater) costs being picked by the organization itself later, the organization's customers and society at large. Moreover, software isn't amendable to the standards of other sorts of engineering and so there's no way to have contracts or regulations demanding software of a certain standard or quality.

Edit: The only imaginable solution would be a technological revolution that allowed cheaper and better software with same technology also not allowing even cheaper and worse software.

Re: The Software Crisis

#95

Post by trinsic2 »

hnthrow289570 wrote: post #49
wryl wrote: 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…

I think this might be premature if you're trying to apply this to how the world makes money with software. There's too much of the economy that depends on adding another abstraction layer to make money, so you'd need to rewire that as well unless we just want to break things. You'd eventually have to tell a business "no" because they're +1 abstraction layer above the limit. I think most of us realize that working at…

I think society has made it convenient for people to lend their creativity to someone else's vision. I don't think its a good idea for talented people to work for corporations that have no connection to the public good.

I don't think its a necessary evil, I think most people either don't want to work to realize their own vision of what they want in the world, or want more than they need and they are willing to sacrifice their soul for it.

Re: The Software Crisis

#96

Post by williamcotton »

marcosdumay wrote: post #81
williamcotton wrote: post #47

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.

I would love to hear your thoughts on how distributed systems lead to deep, narrow and isolated abstractions. I can think of some obvious reasons but it seems like you’ve put more thought into this than I!

Re: The Software Crisis

#97

Post by jrochkind1 »

joe_the_user wrote: post #94
wryl wrote: 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…

I liked the way you showed the problem as ongoing in history. Indeed, the phrase "software crisis" is nice because it references the first point when the situation was articulated. That said, I think the reason the situation is not going to change is clearly economic. That's not saying that bad software is cheaper. But there's a strong incentive to cheap, bad practices because cutting corners allows one person/organi…

Yes to this.

Lately I feel like we have built a society with expansive software infrastructure, where that software is doomed to be crappy and inhumane because our society actually couldn't afford to build this quantity of software well.

So another hypothetical fantasy solution would be a lot less software, like being careful about where we used software, using it in fewer places, so that we could collectively afford to make that careful intentional software higher quality.

Certainly a society like that would look very different, both in terms of the outcome and in terms of a society that is capable of making and executing a decision to do that.

Re: The Software Crisis

#98

Post by brundolf »

This paints abstraction like an evil, but it's an unavoidable tool for any human-made software to reach certain capabilities

Rich Hickey said something along the lines of "A novice juggler may be able to juggle two or three balls, but the best juggler in the world can only juggle maybe nine balls. There isn't an order of magnitude difference in human ability, we hit a ceiling quickly." If we are to surpass those limits, we have no choice but to abstract

Of course there may be bad abstractions or too many abstractions in a given case, which is what I think the author is mad at. But that's an important distinction

This part is also plainly false:

> It is no longer easy to build software, and nothing comes with a manual.

Making software has never been easier or better-documented

Re: The Software Crisis

#99

Post by vbezhenar »

threatofrain wrote: post #14
ramesh31 wrote: post #10

Earlier quoted context omitted.

>The real problem with abstractions is when they are implemented poorly, or have side-effects, or just plain bugs. Which is always, and is why clean maintainable code uses minimal abstractions to accomplish the task. However it seems the default these days has become "pile it on".

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.

There are no perfect abstractions. Or they are extremely rare. There are abstractions suitable for a given task. And as requirements change, perfect abstractions become imperfect and new abstractions are needed (which would be imperfect in the past).

Re: The Software Crisis

#100

Post by vbezhenar »

RaftPeople wrote: post #90
marcosdumay wrote: post #82

Earlier quoted context omitted.

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

User does not want to control optimizations. User wants their queries to run fast enough. Ideally database should monitor the queries and create/remove necessary indices as needed. And some databases do that.
Post reply on HN