The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN.
Instead they spent actual time, effort, and money making their product worse.
My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.
This is honestly a major contributor to the badness of software in general.
Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible.
A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated.
But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
> Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points
This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust.
Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience"
That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product."
And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
Translation: "we're paying all these engineers and product managers and they need something to do"