Ask HN: How do you deal with collective overcomplication?
1. You suggest a relatively small and scoped change that would improve a certain user scenario (let's say 10 lines of code adding a new command to your API).
2. You start discussing it with the team. Everyone usually feels compelled to contribute something, so the complexity starts piling up. Someone would suggest that our old API is inconsistent we shouldn't extend it without restructuring. Someone else would point out that we don't support async requests and it's more "proper" to switch our engine to async and provide an async version of the new API. Another person could say that they've been unhappy with the memory usage forever and we must redesign the internal data representation before we move on.
3. At the end of the discussion you don't have a scoped 10-line change addressing a problem, but rather have a grandiose plan for a major update with massive risks. At this point the team usually loses interest to this and moves on to discussing the next big thing. The change ends up shelved forever.
I've been through this many many times and I've not found a good way to resolve this. If you try to include a good rationale why the small scoped change is optimal, it's usually just ignored. If you try to convince people at step #2 that the large changes could be avoided while delivering the same user experience, you start hearing arguments like "proper way of doing XXX", "should find the optimal way instead of compromises", etc. If you try to bring the topic after step #3, everyone has usually moved on and doesn't care anymore.
I'm wondering if anyone else has encountered this and could suggest a good way of convincing people to not overcomplicate and actually deliver results even if they are not perfect.