|
|
|
|
|
by thibran
1757 days ago
|
|
The real reason is, adding features is simple, you just have to understand the one use-case the feature adds. When removing a feature, you have to understand all the real world use-cases, before you can kill it. This is a lot of work, therefor it is much easier to not touch it and work on the next feature. |
|
A lot of this comes down to shifting the burden within responsibilities of the team. Product management having a good understanding of the hidden use cases is ideal, but really hard. Not doing that means you have Development and QA spending time on stuff no one uses.
One of the interesting outcomes is when you accidentally break a feature. If someone complains at least you know it's being used, and ideally PM starts a discussion on the real use case. My favorite is noticing something is broken while working on adjacent code, and looking at git blame to see it's been broken for months. In theory at least, that should be an easy decision to kill it; in practice my experience is everyone is always very hesitant to actually do that.