Comment by BobbyTables2 | Hacker News Reader

Comment by BobbyTables2 | Hacker News Reader

Parent Full thread

I’ve seen this too and it’s darkly humorous.

We published 1-2 releases of our component each month. Eventually another (internal) team would pick it up along with others, test, and release the combined set maybe 1-2 times a year.

Customers being extremely risk adverse never wanted to update, due to risk of changes combined with the interruption, even though we were fixing serious bugs left and right from the earlier rushed development.

We’d get escalations on things that were fixed years ago.

Probably should have spent another 3-5 years getting the first release in better shape instead of spending 3-5 years flinging flaming turds to the paying customers.

The executives slowly released they inexplicably lost half the business compared to the previous generation as upstart competitors stole their market share.

You know that famous “how shit happens” tale? I’m pretty sure each layer of management was telling the next how powerful the product was… few could abide by it.

I'm not sure that I fully understood but:

> Probably should have spent another 3-5 years getting the first release in better shape instead of spending 3-5 years flinging flaming turds to the paying customers.

I wonder if the company would have had the money to pay salaries for 3 years, unless for those "paying customers" that obviously started paying much earlier than that.

And

> The executives slowly released they inexplicably lost half the business compared to the previous generation as upstart competitors stole their market share.

s/released/realized/ ? Exactly one of my worries. Maybe they could have created those competitors themselves. Two brands, one for the original product and one for a product with a somewhat different layout and all the improvements that they did not dare to add the the original product. But then you need a third brand, a fourth one, etc.

I think software is just very young. We've been doing it for maybe 2 generations. The current way, saas, ci/cd, is like half a generation old.

We're still at the "search" phase, there is very little wisdom at social and personal levels.

It's clear from the rapid flux in tooling, methods, ideology, and the results, that we basically have no idea what we're doing re: using computers and building software. A lot of the self assuredness of current advice is self soothing behavior.

> Customers...never wanted to update, due to risk of changes [...] We’d get escalations on things that were fixed years ago [...] as upstart competitors stole [our] market share.

This is so weird to me, though. Your customers had two choices:

1. Stay with your software and upgrade to the latest version, where the bugs they were hitting were fixed, and risk some amount of retraining due to UI/UX changes.

2. Switch to a completely new, different product, which guarantees retraining (possibly a lot more), and probably would contain the same or different bugs they were fighting with when using your software.

And... they went with #2?? I get that people think the grass is always greener on the other side, but there's a reason why we have that saying!

I suspect they were thrilled at the prospect of a better made product (not encumbered by historical baggage) that cost less, had a lower friction sales process, made by a company actively trying to win them over.

You are assuming the changes would all be positive, minus some UI hassle. I have seen plenty of products where vital workflows were scrapped entirely or made significantly more clunky.

Modern software is quicksand. Maybe an update improves things, but users have all experienced working software made worse.

Yup. Powerful features are removed to "streamline experience". Sometimes in bulk, because product migrated from e.g. bespoke native app to multiplatform webshit in an embedded browser, which automatically halved the performance and removed most ergonomics.

And then new features are released as MVPs - meaning, they do the absolute minimum to check the box (almost a literal box: close the feature ticket internally), and inefficiently so. Whether it'll be iterated on afterwards, depends. Pretty unlikely in the immediate term. They need to "collect usage data to know what to do" first, which means it gets deprioritized relative to moar features.

But that's fine for me. As long as copy-paste works, I can make do with other software, perhaps competing software, or worst case, have Claude find and use some powerful-but-janky OSS CLI tool to do the stuff for me.

I'm less angry at it than I used to. Mostly because I don't have time to be annoyed anymore, but it's true that I've learned to like updates from few companies. That's because after years - years - I've noticed things gradually improving on average. True of Android & Samsung OneUI, except when it's not. True of UniFi stuff. If I see some new feature behaving badly, I now mostly trust they'll eventually fix it. It'll take a year or three, they'll overhaul it entirely twice, and I may need to buy a new phone to get it, but it will happen one day. But most software doesn't even clear that bar.

Yes, they go with #2 because they are really p***.

As anecdote of one, I was once part of a project to port a .NET Framework to Java, because the customer was really annoyed with the rewrite, as the application relied heavily on the .NET Features that never made the cut to modern .NET.

Another two .NET heavy weights in .NET CMS space, Sitecore and Optimizely, nowadays rely on JS/TS frameworks for their extensibility SDKs on the SaaS products for headless deployment, only the classical (older) PaaS still support .NET as extension language.

"Trust thermocline". This happens when people no longer trust that improvements are going to come from #1.

Someone whose partner is about to leave them loudly proclaims "I've changed!". Should they believe them? Often the answer turns out to be "no".

It's quite difficult to actually build back trust in these situations.

Reply on news.ycombinator.com