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

21–30 of 201 posts

Re: The Software Crisis

#21

Post by beepbooptheory »

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 just want to say this was a wonderful log. There are not many in this field who have an intuition or impulse towards materialist/historical analysis, but whether you are aware of it or not, that is certainly what I read here. Just to say, its not quite recognizing how we find ourselves thinking that is enlightening, but rather recognizing why we find ourselves thinking like we do that can bring clarity and purpose.

In a little more woo woo: abstractions are never pure, they will always carry a trace of the material conditions that produce them. To me, this is the story of computing.

Re: The Software Crisis

#22

Post by steveBK123 »

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.

Re: The Software Crisis

#23

Post by wryl »

beepbooptheory wrote: post #21
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 just want to say this was a wonderful log. There are not many in this field who have an intuition or impulse towards materialist/historical analysis, but whether you are aware of it or not, that is certainly what I read here. Just to say, its not quite recognizing how we find ourselves thinking that is enlightening, but rather recognizing why we find ourselves thinking like we do that can bring clarity and purpose.…

Thank you for the kind words! "I appreciate them" would be an understatement.

And I agree entirely. Tracking the history of an abstraction will usually tell you its root, though it gets pretty muddy if that root is deep-seated!

Re: The Software Crisis

#24

Post by wryl »

morning-coffee wrote: post #20
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…

It's hard to get past the hubris wrapped up in the statement "I'll show you how"... as if the tens of thousands of bright engineer's whose shoulders you stand on were incapable and you're the savior... maybe you are! (But just adding the word "try" in that sentence would reduce the perceived arrogance by orders of magnitude.)

Well, that certainly wasn't my intention, but in an environment of "I have a silver bullet and it'll cost you $X", I can understand the sentiment.

At the same time, I do want to show that I have confidence in my ideas. Hubris and confidence must be applied in equal parts.

Re: The Software Crisis

#25

Post by fuzzy2 »

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

Sorry.

Re: The Software Crisis

#26

Post by pmarreck »

The large majority of the work code does can probably be boiled down to a series of transformations done by a hierarchy of pure functions with a fixed number of inputs/dependencies, all of which are easily testable in isolation.

It's unconstrained side effects and dependencies, resulting in an increase in complexity, that seem to cause the major issues and have to be managed.

The real problem, of course, is the human capacity to comprehend (or not) the entirety of the system or subsystem by modeling it correctly in the brain.

Re: The Software Crisis

#27

Post by wryl »

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…

Problems surrounding computing education do compound these frustrations, and I sympathize.

Having worked for larger organizations (whatever FAANG calls itself these days, I can't keep track), as well as academia and independent education, I've seen both halves of the "production line" for newcomers to computing.

Something has to change in how we bring individuals into our field. I have some ideas based on my experiences, but you're not in the wrong for feeling frustrated about this. It is the state of things, and many companies are not equipped to handle it, because it's unexplored territory.

Re: The Software Crisis

#28

Post by kmoser »

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.

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 code is subject to side-effects due to its actual implementation. That's why we have, e.g., multiple sorting algorithms, and documentation for their individual behavior, speed, etc.: so developers can understand the limits and idiosyncrasies of each and pick the correct one for the job.

We may make incremental steps towards more bug-free code, but because everything is limited by the details of its actual implementation (whether real or an abstraction), there is no magic bullet that will make a huge leap forward in the realm of software development as a whole.

Re: The Software Crisis

#29

Post by ChrisMarshallNY »

omnicognate wrote: post #12
ChrisMarshallNY wrote: post #4

> It's catastrophic when they don't." I have found this not to be the case. Very often, an inaccurate mental model is the ideal user state, and it's my job to afford and reinforce it. But that's just me, and my experience. I'm sure there's a ton of folks that have found better ways.

Personally I can't bear software that contorts itself to conform to an incorrect mental model. I find it alien and unusable. I don't want the inaccurate mental model and cannot force myself to accept it, but the contortions and don't-look-behind-the-curtain prevent me from forming an accurate one. That doesn't mean I don't want abstractions. It means I think what constitutes a good abstraction is determined as much b…

> We should have more respect for users

Agreed. In my case, I write software for a lot of really non-technical users, and have found great utility in reinforcing inaccurate, but useful, user narratives.

So "respect" doesn't just mean assuming users are smart. It's also making house calls. Meet them where they live, and do a really, really good job of it, even if I think it's silly.

Re: The Software Crisis

#30

Post by doug_durham »

I reject this thesis totally. It has never been easier to get things done with software. The APIs provided on many different platforms allow useful applications to be developed by a larger number of people than ever before.

I started my career in the era is 8 bit microcomputers. Yes it was great to know the entire stack from processor up through the GUI. But I would never want to go back to those days. Development was too slow and too limited.

We are in a golden era of software development.

Post reply on HN