The examples listed sound like the status quo, even when staying lean in your feature set. The two minor features mentioned simply prompted work that should pr

The examples listed sound like the status quo, even when staying lean in your feature set. The two minor features mentioned simply prompted work that should probably have happened anyway in an active software project. One feature triggered dependency housekeeping (Cordova upgrade), another a refactor that will save time and bugs in the long run (consolidating m many inconsistent form control types). The last example, large amounts of effort to maintain backwards compatibility across major versions, is the one instance of a feature itself leading to what could be considered unexpected work. It's no minor feature though, and it's something I personally wish was considered a hard requirement, but it's understandably sacrificed a lot of the time. Backwards compatibility, when doing major rebuilds, can be the source of some really nasty spikes in work. Every little decision you made in the past is now up for revision, as it comes up against future changes and requirements you didn't even know you needed to account for in your design. A good peek into software maintenance for the uninitiated, though was hoping for a piece about frivolous features causing combinatorial explosions of complexity based on the title.