|
|
|
|
|
|
by secabeen
1907 days ago
|
|
|
> 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. |
|
|
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.