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.
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!
Modern software is quicksand. Maybe an update improves things, but users have all experienced working software made worse.
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.
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.
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.
> 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.
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.
I literally was told not to narrow down the features too much or the product would be too constrained... well then wtf does it actually _do_ for anyone?
So which is preferable - customisability or very limited feature set?
But I would not expect a large percentage of developers to want to do that. I've used IDEs as well, and they're mostly fine, and work really well for lots of people. Many IDEs are pretty damn customizeable too, though most people may not change many settings.
There is no general answer that will answer which is preferable.
It is easy for people to come up with features they want or a customisation and they don't care for the cost of actually maintaining that feature or customisation.
I work on building SaaS platform, we had multiple customers for whom we build custom features and they paid for development of those features. Not fun part is after 2-3 years those customers are gone (for example employees at customer rotated and they switched to something totally different) — but now we are left with dead feature no one is paying for supporting, some are easy to remove, some are not.
The idea is that the user should be able to be productive more or less immediately after installing the software, and then incrementally customize it as they discover they have different needs than the defaults give them.
A lot of developers/companies forget the first part, and ship something that requires a team of consultants six months to set up before anyone can do anything useful with it. Of course no one wants that. (Well, except for the highly-paid consultants.)
This is a classic IDE problem. The IDE has a preferred directory layout it wants, and some other build tool you're using has a different directory layout.
The problem seems to be that there's not many such great abstractions to be found.
I have seen dozens upon dozens of Excel sheets which "just worked" until they didn't and then of course person who could fix that left company 10 years ago.
Besides I also know dozens of people whose life would be easier if they would learn a bit more of Excel like pivot table is there for them.
It is "velocity fallacy" — product people want "all the features ASAP or right away".
Until users with their managers come with pitchforks and torches. I worked on such internal project where we as developers were able to deliver new features and new version every 2 weeks (which is not a pinnacle of the game of course) and were thinking if we can move to daily delivery. Because we were good devs and wanted to appease product owner.
Until one day product owner came back with feedback, how everyone is pissed off at him for shifting ground under people feet, while he also thought he is doing great delivering all those great features. It was pushed back to limited amount of features each month.
People need training, people need to understand what and why.
In the end it turns out it is also AI coding fallacy, because most of the software is built for limited audience, which has its specific timeline on accepting and internalising new features or different ways of doing stuff. Unless we take humans from the equation and we start building for AI itself.