There are dependable ways to reduce an organization’s legacy code, and all it requires is fewer managerial panic attacks.
To be accurate, there will never be much managerial panic if those managers stick to best practice Continuous Integration/Delivery methodologies for design & architecture & implementation & delivery. One of the worst managerial mistakes is the underestimation of time & resources that a particular project will require, leading too often down the roadmap to panicky meetings of mostly finger-pointing insecurity after corners get cut and quality heads south.
Software professionals have diverse opinions about what constitutes legacy code, but a good rule of thumb is that it is any codebase which gets neglected because few want the responsibility of maintenance & upgrade. Procrastination begets workflow ossification, which in turn obligates marketers and consumer evangelists to rely more & more on hubris or even, amid their desperation, outright fraud. After that, organizational bankruptcy becomes all but guaranteed.
Among the cut corners of mismanaged software projects, inadequacy regarding documentation and unit testing appears to be the worst factor contributing to the figurative plate of spaghetti known as legacy code. Such code isn’t restricted to older stuff from (*gasp*) the twentieth century (*gasp*), because whenever any not-nearly-done project faces an impending hard deadline, haste makes for waste.
Documentation and unit testing can dovetail with each other to form a hybrid kind of “characterization testing” solution to legacy code procrastination within a development team. When your SCM has thousands or millions of lines stored yet neglected by just about everyone, try taking a less rigid approach to managing that particular slice of your employer’s slice of the eternal infotinuum.