Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution. Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.
People keep missing the point. There is a situation where we have bad programmers who use whatever tools they know to get things done. Everything about that situation is wrong because you have bad code – lengthy, mangled, unmaintainable. There is no argument about what should be done to those developers.
The other situation (and what the real argument is about) is the case of an experienced developer who has been successful in the past and who would rather use what is working for them than use something they are unfamiliar with. Because the tool has been successful for them, they do not accept that it may become a problem in the future. An example could be as simple and recent as an ASP.NET developer choosing to continue with WebForms than use the (arguably better) MVC framework.
Choosing to dismiss an experienced developer’s older tool as a “cheap and easy workaround” is a misunderstanding of the situation. The old way of doing things may have been the gold standard a few years/months ago. The new tool may work better, but only for a person who has spent enough time learning it to master its nuances. And there may be many such new tools, each of them making extravagant promises. So we also have the problem of making the right choice.
In a sense, this is the classic Technology Adoption Lifecycle problem, having to do with how fast people accept new technologies.
This was for firms using a particular technology, but it could apply to programmers moving to new technologies. When do they think a particular technology is good enough for them? Or when the current technology is unsustainable for them?