> I would want to know if the new system is going to make everyone's lives easier.
If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary.
I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".
It very much depends on who that person in the corner is. I've seen junior devs waste a lot of time doing this. However, I have seen one or two examples of a senior dev solving a real pain-point that wasn't getting fixed within the system, for one reason or another.
Right; for me the determining factors between the two cases are:
1) It is a known pain point, so the problem has been discussed. Probably a lot. The pain is the reason for the code, and if there's a new tool involved, that's additional not a main reason.
2) it's usually a technical task - for example something related to faster, more reliable deployments. This means that the requirements are already well-known by the engineer, and that it probably hasn't been addressed yet as it's hard to tie to a business benefit.
3) Experience of the engineer. Senior devs are more likely to chose a good target.
If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary.
I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".