[tziki]

Something like this should be part of every engineering curriculum. As a small anecdote, I've several times ran into engineers who spent inordinate amounts of time to make the system just a tiny bit more type safer, and when I ask how many bugs would this have fixed during the last year they don't know. When I do the work and send them the single, low-impact bug their efforts would've fixed, they still go through mental gynastics to justify their efforts.

[iib]

A thing to keep in mind in these situations is that making the system a bit more type safe may be more personally satisfying for the engineers. They may see that as a more worthy goal than fixing `n` additional bugs.

Same thing with premature, or otherwise unnecessary, optimization. Sometimes it's just fun!

[harterrt]

Author here. I fully support prioritizing a project because it's fun! We need to own that rationale though.

In OP's situation, it sounds like their counterpart is trying to argue that this project is a "good thing to do" for the user/system. In reality, it's a bit of code hygiene that makes it more fun to do work (still important [1]).

That dissonance hides the true value of the work and makes it difficult to reason about.

[1] https://blog.harterrt.com/bad-tools

[harterrt]

Thanks for the note! Doing opportunity sizing early in the product life-cycle definitely helps with this type of situation. Though, I've found it only really helps when it's a forward looking analysis or (rarely) when part of a no-blame retrospective.