It seems like their pet food business (where they were competing with input-intensive meat products) could genuinely have been sustainable, if they hadn't taken so much time to figure out that competing on livestock feed is hopeless.
The partial overlap has been in this state now for years and years. I still have to access the control panel for network device control, sound control, and some of the advanced sharing settings. I thought it would be a short transition but now we just have crappy partial duplicates of settings and ui styles scattered around this half baked migration. When I open the disk volume management it's like I'm back on Windows 2000 for some reason.
Regular volume management can be done entirely within the Settings app. So can sound settings. There's probably an outlier that diskmgmt does better, I'm sure. But diskpart still exists, too. It could be that MSFT targets only the common scenarios and the fallback ends up being old utils/PowerShell at some point.
As far as I know, to modify the audio Exclusive Mode settings and view jack information, you still need to use mmsys.cpl from the Control Panel. And I think many operations like converting MBR to GPT still require the Disk Management control panel.
Waving it away as little-used features is not an excuse, it's the entire reason things got this way. That's why we have layers upon layers of half baked UI with "only" the controls that "everyone" needs. Because those rationalizations are wrong and this is the result.
And seeing as Windows is now a nightmare, and I am a technical person, I’ve moved everything to Linux.
Everything is still harder to get set up right on Linux, but it stays right. I’ve also found the LLM’s dramatically shorten the time required to configure things I don’t have experience with.
MS have abandoned their power users, and the power users (some of them at least), are abandoning MS. I keep Windows around in a VM for work purposes; never had a better setup! I’m in complete control of my PC again.
Somehow macOS only has one System Settings app. (They did admittedly make a mess of it lately, but in an entirely different way than Windows.) And yes, they relegate a lot of advanced stuff to the Terminal.
Honestly I always hope that what I try to do, is still possible with the old Control Panel, since there I at least get understandable descriptions and can actually change things instead of the marketing speech and locked down settings in that abomination called "Settings app".
Not OP, but I think building feature flags yourself really isn’t hard and worth doing. It’s such an important component that I wouldn’t want to depend on a third party
I agree, but it's hard to get the nuances right. It's easy to roll out a feature to half of your user base. It's a bit harder to roll a feature out to half of users who are in a certain region, and have the flag be sticky on them.
We use Unleash at work, which is open source, and it works pretty well.
I generally agree, but see some more nuance. I think feature-flagging is an overloaded term that can mean two things.
First, my philosophy is that long-lived feature branches are bad, and lead to pain and risk once complete and need to be merged.
Instead, prefer to work in small, incremental PRs that are quickly merged to main but dormant in production. This ensures the team is aware of the developing feature and cannot break your in-progress code (e.g. with a large refactor).
This usage of "feature flags" is simple enough that it's fine and maybe even preferable to build yourself. It could be as simple as env vars or a config file.
--
However, feature flagging may also refer to deploying two variants of completed code for A/B testing or just an incremental rollout. This requires the ability to expose different code paths to selected users and measure the impact.
This sort of tooling is more difficult to build. It's not impossible, but comparatively complex because it probably needs to be adjustable easily without releases (i.e. requires a persistence layer) and by non-engineers (i.e. requires an admin UI). This becomes a product, and unless it's core to your business, it's probably better to pick something off the shelf.
Something I learned later in my career is that measuring the impact is actually a separate responsibility. Product metrics should be reported on anyway, and this is merely adding the ability to tag requests or other units of work with the variants applied, and slice your reporting on it. It's probably better not to build this either, unless you have a niche requirement not served by the market.
--
These are clearly two use cases, but share the overloaded term "feature flag":
1. Maintaining unfinished code in `main` without exposing it to users, which is far superior than long-lived feature branches but requires the ability to toggle.
2. Choosing which completed features to show to users to guide your product development.
(2) is likely better served by something off the shelf. And although they're orthogonal use cases, sometimes the same tool can support both. But if you only need (1), I wouldn't invest in a complex tool that's designed to support (2)—which I think is where I agree with you :)
> In the last thirty days, I landed 259 PRs -- 497 commits, 40k lines added, 38k lines removed. Every single line was written by Claude Code + Opus 4.5. Claude consistently runs for minutes, hours, and days at a time (using Stop hooks). Software engineering is changing, and we are entering a new period in coding history. And we're still just getting started..
A long time ago, I was having a discussion with my clan leader about luck in video games. He said that the better you are, the more lucky you are. Luck and skill go hand in hand. That's always resonated with me.
They are annoying to setup and maintain and contain footguns. I will still use them with prek though because they save dev cycles back-and-forth with CI more than they hurt. I aim to have the hooks complete in under 1 second total. If it saves even a single CI cycle, I think that's a win time wise.
reply