HN Explorer

Ask HN: How do you deal with collective overcomplication?

3 points by john_moscow ↗ HN
Throughout my work as a developer in several software companies I've noticed a pattern that prevented many features from actually being delivered to the users and have not found a way around this. The situation usually evolves as follows:

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.

1 comment

[ 2.3 ms ] story [ 10.5 ms ] thread
itamarst
Notice the whole conversation in point 2 isn't about the user, or the business, or any goals. It's about "software quality" in the abstract, with no reference to the real world situation.

This is why I think the idea of "bad code" is harmful: best practices are very specific to organizational goals (https://codewithoutrules.com/2017/11/07/no-such-thing-as-bad...).

Given it takes time to get people to see the world in a different way (starting with external goals and working your way down to implications of code), it's unlikely you can convince people in the short term. So this devolves to an organizational problem.

1. You need someone to set priorities based on what the product and users goals are, which is to say a product manager.

2. Alternatively, you can go work for a startup. There you often get to see the opposite failure mode, where expediency rules and the result is often an engineering disaster :)

3. Finally, this particular failure mode is an intermediate experience failure mode. Experienced enough to notice when things aren't ideal, not experienced enough to know when it's OK to compromise. So you can also try to find a place where engineering leadership is sufficiently experienced that they'll make sure things gets done.