[jolux]

There's the "Settings" UWP app, and the older Control Panel, which itself launches lots of even older settings dialogs at various points. It's not actually good for usability that there are multiple places to change the same settings, but what's worse is that they have disjoint functionality. Some things can only be accomplished with the older Control Panel, and some things can only be accomplished with Settings. I find it hard to believe you haven't discovered this, it was an almost daily annoyance for me.

[secabeen]

Okay, so lets assume you're the product owner for Windows settings. You have full, dictatorial control over the Windows settings experience. Windows 7 has reached maturity, and you and your team are starting planning for Windows 8 and beyond. You have identified a number of major flaws in the Windows settings experience, and you want to update it for the future. What do you do?

Note that the Windows settings codebase is huge, has thousands of possible settings options that you can set, and the specific esoteric behavior of those settings is relied on by users, developers and sysadmins every day.

MS clearly decided to re-do the settings system over multiple Windows generations because it was too big to do in a single release cycle. During the transition period, both Settings and Control Panel tooling will be available, and used by many users. Is there any other alternative?

[jolux]

>MS clearly decided to re-do the settings system over multiple Windows generations because it was too big to do in a single release cycle. During the transition period, both Settings and Control Panel tooling will be available, and used by many users. Is there any other alternative?

Windows 10 was released in 2015. It's been like this for six years. Things have improved incrementally over that time period, but there's just no excuse for this situation still existing. If you can't get it into one release cycle, the solution is not to release whatever half-baked thing you've finished and try to keep going with it, the solution is to wait until it's done. The current situation is strictly speaking worse than both replacing it altogether or not replacing it at all.

[secabeen]

> the solution is not to release whatever half-baked thing you've finished and try to keep going with it, the solution is to wait until it's done

YMMV, but this approach is what causes software projects to balloon way beyond initial time requirements, and to be way out of date already when eventually released. If you're hacking on the train while it's running down the tracks, the only way to get there is small, frequent, incremental improvements; waiting until it's done will just result in it never releasing, or in the released version having tons of bugs.

[jolux]

>YMMV, but this approach is what causes software projects to balloon way beyond initial time requirements, and to be way out of date already when eventually released.

This is why you need to determine what your MVP is and ship when the MVP is done, rigorously. In this case, either they chose the wrong MVP, or they shipped before reaching it. Thus the current situation is a result of indecision, not agile methods. Agile is not an excuse to ship half-baked software.

Here's how I would have managed this project, for what it's worth: if we determined that migrating fully in the allotted cycles was infeasible, I would have moved all of the settings we didn't have time to migrate from the Control Panel into a command-line tool or registry keys, gotten rid of Control Panel when I shipped Settings, and then incrementally added the ones we missed back into the new view. What infuriates me most about Windows are compromises like this, which are plainly a result of prioritizing existing user workflows over creating a consistent user experience.