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

61–70 of 201 posts

Re: The Software Crisis

#61

Post by adamrezich »

wvenable wrote: post #52
jdbernard wrote: post #44

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…

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.

Re: The Software Crisis

#62

Post by asdfman123 »

wvenable wrote: post #35

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…

The article doesn't do a good job of explaining what they determine the actual crisis is. Complexity in and of itself isn't a problem. The problems you listed, however, are.

But I don't think that's the real motivation for articles like these: the real motivation is that things just seem out of hand.

But I think as an experienced programmer you have to balance that feeling of overwhelm with what needs to be done. It's taken me a while to arrive at this conclusion, but I believe it's important. Things will never be completely figured out and you have to be okay with it.

Re: The Software Crisis

#63

Post by RaftPeople »

jdbernard wrote: post #44
wvenable wrote: post #35

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…

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…

> The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality.

Completely agree with this. The number of good+reasonable solutions is almost infinite, and the number of bad solutions is also almost infinite.

What makes it even worse is that we really don't have a good method of communicating the design+structure of our models to others (tech and non-tech). As the system gets more complex the issue gets worse.

We carry so much info in our heads about system models, and that info is painstakingly acquired through inefficient communication methods and trial and error and thoughtful analysis.

It would be amazing if we could create tools that allow us to describe the essence of the model and make it directly available to our brains so we could all collectively reason about it and manipulate it collaboratively.

Re: The Software Crisis

#64

Post by TeMPOraL »

fuzzy2 wrote: post #25
UweSchmidt wrote: post #15

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…

The perceived misery you describe I feel is self-inflicted. Many devs "below" me have become entirely disconnected from customer needs, instead only focusing on "interesting" dev problems. Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it. Do I sound frustrated? I am. It…

> Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it.

I think the reason is entirely different: ticket-sized portions of requirements are the only thing that one can hope to estimate in any useful fashion. Business side needs estimates, so they create pressure to split work into pieces they know how to handle.

Put another way, it's not that developers are "too dumb" to wrap their head around actual requirements. They're not allowed to. The business prefers devs to consistently crank out small improvements, keep "velocity", even though it leads to "organically" designed systems - i.e. complex, full of weird edge cases, and smelling of decay. The alternative would be to let the dev talk, design, experiment, take the project holistically - but that also means the work becomes impossible to estimate more precisely than "sometimes next year, maybe", which modern businesses can't stand.

Re: The Software Crisis

#65

Post by wvenable »

adamrezich wrote: post #61
wvenable wrote: post #52

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…

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

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.

Re: The Software Crisis

#66

Post by pauleee »

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.

Re: The Software Crisis

#67

Post by asdfman123 »

UweSchmidt wrote: post #15

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…

In big tech lots of managers are highly technical all the way up.

But there's two problems: they can't get into the weeds, and they also are subject to the perverse incentive of being rewarded for generating complexity.

Some people fight it, sure, but those who fight it are less likely to be promoted. You don't get rewarded for having less staff under you or eliminating your own role.

Re: The Software Crisis

#68

Post by intelVISA »

steveBK123 wrote: post #22
UweSchmidt wrote: post #15

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…

I could buy this argument. Had I been a junior during the agile era, I'm not sure I would have developed as fast or as far as I have. The most agile pilled company I worked for just treated juniors & seniors as interchangeable cogs, except seniors should be able to clear more points per sprint. Active discouragement from thinking outside the scope of your ticket, keep your head down and mouth shut.

> juniors & seniors as interchangeable cogs

welcome to the car factory

Post reply on HN