p.enthalabs

Software may be getting worse, but it used to be horrible

bitlog.com · Read Story HN original

Comments

Probably the most annoying bug I ever encountered was in Quark Xpress 7 when in a two-column layout, placing a discretionary hyphen in a paragraph on the right-hand column caused a preceding paragraph on the left-hand column to reflow to a different number of lines. I tried to get Quark to look into it (it was perfectly repeatable) --- when they wouldn't, I pulled a couple of all-nighters over a weekend and shifted the entire project to InDesign.

That said, as a counter-point, there were also applications such as WriteNow which was ~100,000 lines of hand-coded assembly, which was quick and performant even on an 8MHz 68000 Mac Plus --- it flew on a 25MHz NeXT Cube (it was originally developed as a possible advanced MacWrite/replacement for it if it didn't ship, then was contracted by NeXT to make a bundled word-processor)

https://www.folklore.org/The_Grand_Unified_Model_The_Finder....

Thank you for that link :-) I miss the old MacOS, often..
It was simply a magical thing in the early days, and one wonders how things would have turned out if for instance we had had MacBasic instead of HyperCard:

https://folklore.org/MacBasic.html

https://www.folklore.org/Joining_Apple_Computer.html https://www.folklore.org/Evolution_of_a_classic.html

(and it kind of kills me that there isn't a book on the history of HyperCard --- a quick search did turn up:

https://www.taskade.com/blog/hypercard-history

which seems promising (if a bit self-serving and possibly AI-generated.... will have to find time to read)

All of these are examples of the physical performance of software or hardware limitations at the time. I find that software's reliability has increased a thousandfold in my lifetime, but its actual controllability/feel/UI-UX has been rapidly declining for about a decade.
I think you and I align closer to Robert Pirsig's ideas on quality. It feels worse, so it is and you can't really measure it.
You can measure UX. Just ask 100 people "does it feel worse? did you like it better 5 years ago?"
Direction is right, but more rigorous is A/B testing to learn what people actually prefer.

Stated preference is very often different from demonstrated preference.

A/B testing does not inherently lead you to good design. If you A/B test what people want based on their revealed user preference, you get gambling apps and doomscrolling.
"I want a steak dinner." Yeah, but based on usage patterns, here's some cigarettes and beer. /s
All of the pizza chains from my youth A/B tested their ingredients into a weird hill climbing problem. They are all worse tasting and more expensive but despite tasting very differently they are basically equal in how good they taste. You can't really say one is better than the other but they are definitely all worse than they were before.
I would be careful with trusting the answers to those questions.

People remember things to be more positive than they were. This is an established bias in human psychology

https://en.wikipedia.org/wiki/Rosy_retrospection

Fair point; to correct for this bias, ask n people to rate their experience with software reliability, then wait five years and do it again. The larger your n, the more you correct for individual variation (via the Law of Large Numbers)
1) Asking five years apart only confirms if the bias is stable/changing. It doesn’t correct anything.

2) Asking more people gives you an answer closer to the ‘truth’ (i.e. the true population mean; the mean answer if you asked ‘everyone’). It lowers sample error, not directional bias.

You're right. Better keep to not asking and just weirdly spy on them, concluding the emergency recovery buttons are never used, and remove them.
I think that’s a non sequitur…
To be a bit difficult, depends on the 100 you ask. Yes yes statistical sampling, but I think my point here is more about how generations are trained growing up.

A lot of people dislike change and sure as shit hate relearning a skill they didn't enjoy or have aptitude in the first place. I know exactly what kind of UX my dad prefers and he HATES all modern design patterns. I think several of them are great for information density and despise everything twitter popularized. Entire generations have grown up on twitter and they think it's basically the only way to display information.

Point being when we're discussing as large a surface area as "software" I'm not really sure you're going to get much out of asking 100 people except what decade they were born in and what software/patterns they grew up on. Clearly some things can outcompete others, but inertia and network effects drive adoption, and can turn people from "ugh I hate this" to "ugh why would you do anything other than this".

I can measure the number of times my computer blue-screens and just dies. It used to happen all the time, and now it never does.
Yeah but they keep moving the buttons for no reason and somehow 34GB OS updates only result in rounded corners and less functionality.
Funny to see this comment here. I was just thinking this morning whether the socratics or the sophists would be more alighted with conversational AI
Bit didn't it also feel bad back then, you just forgot about it and has a rose-tinted view of the past?

Like software used to crash, were single-threaded and constantly frozen. How many times did you have to issue Ctrl+alt+del vs today? Even UIs were constantly out of sync with the underlying data, I would even go as far to claim that reactive frameworks like react cut down a big category of software bugs.

For me I think the difference is that software never used to be actually important, it was either games or just otherwise hobby software.

Now when something crashes I actually need it for work, or to bank, or to navigate, or hell sometimes the only menu at a restaurant is a QR code but my damn phone is failing to recognise it again.

When you introduce technology into every facet of life, it's suddenly death by a thousand cuts when things don't work, or are a slow buggy mess.

I agree. Though some software pain used to be more intense (blue screen of death, etc), our lives have become more deeply enmeshed into software, so we feel the friction more. I think we also expect a lot more from software in our daily lives than we did 20 years ago.
Well, banking is digitalized for a long time (such a long time that they actually are using mainframes and cobol), and it's definitely not the epitome of good software, so I think it was always important, maybe we were just less directly reliant on it.
This definitely plays a role, and depending on your use-case the “stability” of your software and system varies greatly. E.g Messing around with mods could leave your game in an unplayable state (to the point it just wouldn’t launch properly), whilst today you just download/install them from Steam workshop with 1-click.
i think crafting software has turned into something like making music. consider the movie Trolls World Tour, where there used to be one way of making it, then it splintered off into a ton of different styles.

everybody only likes their own style, and has trouble dealing with other people’s style.

maybe that’s what you mean by the total net feel/experience decreasing. in my world, it’s still harmonious, but it’s possible queen barb hasn’t showed up here yet

I think there's a lot of truth to what you're saying, but a lot of software platforms just can't be customized and mastered like they used to. Things like reorganizing columns, setting shortcuts, menus being consistently organized and accessible using the same command, clickable text and elements looking visually different from unclickable, a wide variety of colors being streamlined to color/pale-color/off-white trios, etc. I use a lot of operational software and every platform just can't be mastered like the old stuff. (And animation lags, too!) And I can watch my younger coworkers on the new software packages, they're certainly not faster on the new stuff than I was on the old stuff.

A few months ago my dad and I roused out the old Windows 2000 computer we used from 2002-2010 and while it took about 6 minutes to boot up, once it booted up, the software was all astonishingly fast (no telemetry) and way, way more "commandable" than their modern equivalents. It was like a tool shop.

What happened is ordinary people started using computers. In the early days of the industry developers could assume a reasonable ability in their users. As computers and smart phones became ubiquitous they could no longer continue with that assumption. You see reorganising columns as a feature, the average user is totally confused and stopped in their tracks when they do it by accident.
In college during the late 80s, working at the campus computer lab, I remember telling one student that she needed to use the mouse to move the cursor. She lifted it up and waved it in the air.

Not quite Scotty in Star Trek IV, but close.

I think there’s two separate things going on here.

One is that software started being designed in a one-size-fits-all manner for a “uniconsumer” that vaguely represents every user the software will ever have. Personally I think that analytics-driven development is largely to blame here; through those you don’t see user groups, just numbers going in whatever the product manager deems to be positive and negative directions. We don’t design for specific users, but rather to produce desired metrics.

Second is that professional UI design got flooded with designers from other disciplines (e.g. print design) who only really understand the visual half of software design. The functional, interaction, and user research parts completely fell by the wayside as the job became more focused on coming up with designs that would do numbers on Dribbble and look pretty in a product page or presentation and is driven mostly by vibes now.

> consider the movie Trolls World Tour

can you elaborate?

i was running into random crashes with fusion360
The business models have become more extractive robbing users of control and agency and herding them to places where the business wants them to be.
I agree with reliability of software getting so much better. I still remember Windows Millennium (Something between 98 but not Windows 2000) and it has been a mess.

Further more I still remember software developers in the 2000s who just refused to do any kind of testing on produced software, because it is just a waste of time. It compiles? It ships!

Not many people are such cowboys today.

Sure, but last year I had to reinstall Windows because they did not bother to test USB input devices on their new "recovery" feature: https://techcommunity.microsoft.com/discussions/windows11/th...

All it had to do was run Check Disk, but it kept going in a loop every 30 minutes checking their "AI" for solutions, finding none. There was no way to get out of it.

I am sorry, but even in the worst days of Windows, this would have been a huge deal. This was the last straw so I installed Mint to play games.

> Not many people are such cowboys today.

Now-day, it is the llm that write tests. Nobody look at it and verify if it is meaningful. If the test pass, ship it.

It still cowboys days

Amen to that. For the first time in my life terrible UX costed me money and I'm highly suspicious that fucked up UX is because of AI slop.

Basically, I tried to buy a train ticket on sbb.ch (it was an eurostar crossing the border, so I couldn't do it through the app).

I selected the day and start looking at the available trains. Before continuing I logged in with swisspass to get my halb-tax discount applied. Once done the page reloaded, I got the updated prices, I selected the train at the time I wanted and I purchased the ticket. Only when I got the ticket delivered on my app screen I notice that it was for the current day and I couldn't reimburse it.

Basically, the page reload after the swisspass login changed the date to the current one and, of course, I didn't notice. It is now fixed, but it costed me 90 bucks and couldn't really do anything because technically is my fault for not noticing it was on the wrong day.

Yeah shit like this is/was always extremely common on any kind of app created in the last 30 years. It's not related to vibe coding.
I still get Windows 11 BSOD. That definitely hasn't gone away!
Since Windows 7, which was I think almost 20 years ago, I've seen a single BSOD.

I've seen more on MacOs/OSX in the same time frame.

I’ve seen them from AMD and Nvidia drivers.

Antivirus on my work Windows laptop has caused countless BSODs. VPN clients are often junk.

I had a KVM that could occasionally trigger one.

Windows itself seems to be pretty BSOD free. It is almost always something installed after or hardware.

I still see BSODs on random public displays all over the world while traveling.

There's got to be a subreddit for that I'm sure

Sure they might be using older unpatched Windows but it only reinforces its reputation of being crap and perpetuates the meme.

Eh, take a pic of the BSOD and see what the error is based on. Having worked support for a long time you'll commonly find those things are bad ram or overheating hardware.

Quite often you'll see non-windows displays like that crashed too.

Personal anecode of course but last time I've seen one was around ~2010.
Commonly that isn't a software issue though, that's a hardware problem being [correctly] indicated by software. With three notable exceptions:

- Windows 1.0 through ME era: Legitimately an unstable OS due to dangerous memory model/lack of memory isolation.

- Windows NT through XP: Before KPP was added, software was monkey-patching the kernel, and it was causing instability (particularly multiple trying to over-patch each other). For example during that era it wasn't UNCOMMON for antivirus to do so as a matter of course.

- Windows Vista Specific: They made significant changes to the driver model of several popular device types, and manufacturers weren't ready. So a lot of driver-related failures.

But since then, it has mostly be smooth sailing. If you see a BSOD, you can trace it down, and more often than not the source will be underlying hardware failure which is why BSOD exists and isn't a software bug or problem.

I still remember when Vista had just come out and I installed it on my computer. I was getting such annoying hangups and blue screens constantly.

Turns out it was my sound card, or at least it's drivers. It was some super cheap Crystal-based one. It would have some glitch during the permissions swap of the UAC environment, and when it went to play that ding it would break the system and require a hard power off. If I muted the computer before the UAC, it was fine.

Pulled the sound card and it ran fine.

And even that got worse - now there's no driver name, exception address or stop codes, so you can't even web search for anything.
All of this is logged just the same in event logs. It's just not displayed right on the blue screen message.
No Internet for us back in the day with its myriad of issues. Just BBSs and screaming at the family when the carrier dropped and you wanted to know who picked up the phone.
I feel this is an apt description of our times. It's getting worse but people forget how horrible the past was.

I, for my part, as much as I dig a little 70s and 80s retro stuff, would never ever want to go back.

Try out MVS-TK5, genius differently and opposite of horrible ;)
The real issue is it was secure just by human hacking skill cap and not a wide adaptation of Internet early. now with AI everybody just needs compute and can just run their own hacking operation.
IMO it's a bit more nuanced than what the author portrays it as. Broadly, software used to be much worse on the micro-level but better on the macro-level i.e. architecture.

Since it was much harder to make stuff, you really had to architect it well or otherwise it would simply fall apart. For example in assembler you need discipline in your calling conventions, layout and so on, otherwise it just corrupted, you needed to follow sensible naming conventions otherwise it degenerated into unreadable label spaghetti and so on.

Nowadays it's the other way around, the micro level is so much better due to libraries, code reuse, LLMs and better languages/tools, you can use highly sophisticated data structures and functions at your fingertips. In exchange, you can afford to skimp on architecture because computers are fast anyway, and the programming languages don't let you make a huge mess. (Most don't have unstructured goto/jumps, can't corrupt memory accidentally, etc.)

However, this has the cost of making larger programs a nightmare to maintain and systems suffering from a "death of thousand cuts" i.e. on the micro level all is well but when you look at the entire system it's a sprawling unreliable mess. This is where rewrites often happen ;)

Counterpoint - lots of old systems have atrocious architectures.

Those downsides existed, but then that’s just how lots of stuff is or was.

Larger systems are not imo any worse to manage now, but the scale of what is possible and expected dramatically changes what we consider a large system these days.

I think this is like looking back at a few hits and being nostalgic for some decade of music forgetting all the terrible songs of the time. Or perhaps if the volume has increased seeing on YouTube all the school bands that you’d never have seen before because recording was expensive and distribution reserved for the very few.

Not disagreeing, but I feel there is something to be said about how the tools we use nudge us to do things a certain way.

Similar to how using lambda functions and some document DB is easy and fast, but it often times leads to shit architecture as you don't have to think about it anymore, bolt on whatever cloud service X and Y for features and you have a mess.

AI is similar to cloud in that way, it's so forgiving that it pushes you towards a shit architecture as it "doesn't matter anymore".

Funnily enough AI makes the cloud mess easier to manage. These opinions are based on my own experience and most importantly, vibes.

Architecture is still important for large systems. And there are tons of legacy systems with spaghetti code.
“Software is degrading for obvious reasons” is just painfully lazy. Where are the metrics of degradation? Where are the claims of specific reasons, and the evidence of causality?

If the complaint is vibe coding makes bad software, I largely believe it, but I absolutely believe that vibe arguing makes tissue paper arguments. “Everyone knows” and “it’s obvious” are flimsy things to rest arguments on.

I’m writing dramatically better software for all the reasons this post says obviously make worse software.

Testing has gotten much easier, and bug fixing has gotten much easier. I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1. The old project had no accessibility considered at all, the new ones are nicely done aria and beyond. Old project is stuck on old libraries because upgrading is a major pain. New projects take new libraries (after cooldown) no matter the effort.

So I’m left thinking that perhaps some people, too lazy to use the new powers of new tools, churn out the same or worse quality code/essays.

But I am seeing a lot of very high quality software that simply wouldn’t have been possible before, and I believe the same could be done with essays by leveraging these tools to research and find real data beyond “it’s obvious”. But that does take a lot more work.

> But I am seeing a lot of very high quality software that simply wouldn’t have been possible before

cite 1

Probably his own vibe coded stuff.
I imagine a github repository with a README and no source code.
Zero bugs, though.
Dawg, you clearly haven't used any consumer-grade software in the past 5 years. Everything across the board is a worse experience and there in some cases are limitations that make no sense. Use any app such as Spotify or Uber Eats, its a worse experience than it was 5 years ago, hands down. Everyone outside of our bubble knows it.
> worse experience

This too is subjective.

No one designs for users any more. It's all gas no breaks on the path to enshitification. A lot of this is the motivation of the people building software.

Raise your hand if you ever saw a PM get promoted for removing a bunch of bad and/or unused features?

Those aren’t consumer software though.
What do you mean? These are desktop operating systems for end users.
I have long suspected that one of the driving issues is the continued need for people in the org to keep justifying their existence.

From the consumer POV you can make a great app that does the thing great, and then that's it. Pay once upfront. Just security updates and maybe light compatibility updates after.

Instead we get constant toying and adjusting, and even worse, get pigeon holed into a monthly subscription to bankroll the $200k salaries needed to pay the team that hides the menu button every 6 month to boost screen time.

> I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1.

Goodhart's law etc.

lazy low context response to a comment about lazy arguments.
Should an AI have expanded it to 3 paragraphs to say the same thing?
Test cases doesn't mean shit works. It means test cases pass.

About 50% of the test cases I've ever seen are pointless.

IME, nobody reads the tests in code review either. They just see "looks like it has tests" *check*. Many times, I've caught LLMs writing completely vacuous tests for configurations of components that were impossible. But coverage number go up, so those tests get written.
Test cases are an indicator. They say that this situation I thought of works as I think it should. It doesn't cover everything, but it does cover a large number of things.

A test is mostly useful only in the case that by failing it alerts you to a bug.

I was reviewing some coordinate conversion code one time and a developer’s method of creating unit tests was to run their code, generate a result, then make that output the correct result for the test. Except the result was wrong based on other utilities doing the same conversion, and also failed edge cases.
For the inexperienced dev audience: generally speaking that is a valid way to generate regression tests and document novel edge case behavior.

In your case of course any existing utilities behavior/specs should be tested first, regression tests just on top, if they are not already covered.

I've seen a coworker ship a test that contained a=1; assert a == 1.

Yes it was vibe coded. The "a" variable was never used, and was tested to be 1 several times.

It was several hundreds lines of course so I didn't bother reviewing the rest.

I've thought about this, tests should be easier to add to your modules. We dont' need a ton of tests, but we need them to be in more places.

Tests fix how the software can be changed and when software-spec evolves lots of tests can become obsolete. Maybe with AI it is easier to change the tests (?) which is good.

But there is another purpose for tests, besides "testing". It is to document your modules in a way that shows you how to use them, and let's you easily verify is this still working, can I trust it.

> I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1.

Lines of code is a poor metric for measuring, both for application code and testing code

While in general that is true, this is one person and so we can assume a lot of the variables that make it a poor metric are constant in this case and so we can draw a few conclusions.
From my own experience, LLM generated code having more test cases is neither surprising nor an indication of improved quality. I've found LLMs are quite good at making lots of test but the tests are often not that useful. I would argue that total count remains a poor metric for quality.
I don't know of a good metric for quality. Total count of tests is the best I've found, but I agree it is bad.
Ask for red-green tests. Without that they are often indeed useless.
We can conclude that there are more tests per code perhaps. We can't conclude they're adding value.
my experience is 25% of valuable. Which is a lot better than nothing.
> But I am seeing a lot of very high quality software that simply wouldn’t have been possible before

Personally, I haven't seen too much of that. What I've seen is software that _looks_ pretty, has a shiny interface, a well-designed animated website made with god knows what, but under the hood it's a bit of an alpha mess....

When your software crashes and doesn't do what it's told I will think back on the thousands of bullshit tests Claude wrote and feel less bummed out about it. (Maybe.)
There is plenty of evidence. For example:

https://www.youtube.com/watch?v=MR4i3Ho9zZY&t=37s

The reason is clear - without scarcity of compute or memory, performance is no longer a feature. That works until all the laziness compounds into a crawling bloat.

This is regarding desktop software. With services, microservices is basically a performance anti-pattern that is used without any due diligence in most cases.

"hey Claude, rewrite it in rust"

I'm semi-sarcastic here, but this is actually possible now, while it was an often futile and very expensive roundtrip before AI resulting in two versions of your software that you have to simultaneously maintain.

I always say - "give me the fastest baseline framework and I will destroy it with one bad SQL query".
> "hey Claude, rewrite it in rust"

Things get lost-in-translation, and Claude doesn't seek your input for decisions that matter.

The headline makes not much sense though. If the software used to be horrible, and now is getting worse, then what is the result? Abysmal software? In the light of this decrease of quality, the "but" seems misplaced, as if it indicated, that it is not so bad, while in fact software getting _even_ worse, will make some software unimaginably bad and we should worry even more.