This isn't necessarily restricted to software engineering, but I'm asking here because I'm curious to know if there's a specific phrase used within the context of SE, as it's where most of my Q&A activity is performed..
For a long time I've used various community-help resources such as SE, EE, forums, even IRC and similar, places and overwhelmingly I find that people come asking for help do so in one of two ways:
- The have a set of requirements for inputs and outputs or some kind of program spec, no idea how to get from one to the other, so theyre asking for help, pointers, or someone to do it for them
- They have had a stab at implementing a solution, and it sucks - it's not to spec, does things in a terrible way, only works half the time etc
Those in the second group are sometimes harder to help because they're emotionally invested in their crap solution - it's taken hours to write, it looks like it might be the thing they need if they can just work out that last bug.. But really it needs throwing away and doing over, better. They will, however, pester for help fixing their broken solution, rather than accepting offers of help solving the actual problem
Is there a name for the concept, either:-
- for the notion of "fix the problem not the problem with that broken solution" or
- a (possibly particularly SE oriented) name for the emotional affliction that prevents them from taking this better way/throwing all that junk code out and starting over etc
I'm curious because I'd like to be able to say "this is a recognised phenomenon called XYZ, have a read up on it and how it's harmful to your overall development as a software engineer and how you should avoid it.. then come back and we can fix the actual problem" in a SE flavoured way (like, I'm sure teachers have their own context word for cardboard analysis/rubber duck debugging).
(ps; I really struggled with tags for this one, open to suggestions [including "not a good fit for SE"])