Eventually, old tools need to be replaced. Really. Perhaps most of us won’t insist on using this drill.
Many have argued that its better to update/refactor than to completely replace. However, even old tools have lifetime limits. What criteria would help with this decision?
Projects developed largely via on-the-job-training (OJT). (See previous blog.) The burden embodied within such a project has long crushed productivity, time to move on.
When there are little or no unit/automated tests (you have nothing to lose). It’s true that the lack of automated tests are a hardship, but it’s likely that developing these tests for the old technology will simply be limited in use.
If your product suite hasn’t harnessed common productivity gains, each component has its own set of unique bugs. The rewrite or replacement affords the opportunity to get this done.
If your baseline technology was all the rage 10 years ago and has since languished, your risks are many and exposure grows daily. Is the technology being updated for security vulnerabilities; how is the talent pool going to get filled; can the old architecture support new technologies; how active/broad is the community support online? There are likely very competitive open source alternatives.
When the baseline technology environment is so entangled with old ways of doing work, it struggles to keep up with faster paced changes (for example, if it has its own editor and cannot support a plug-in editor). Clearly this toolset is behind the productivity curve, with a low probability of catching up.
Basically, like any tool that has a falling productivity advantage, not much analysis to support the change is needed. Does a new battery-powered, keyless chuck drill appeal to anyone?