How to justify rewriting/revamping legacy software in a business case?
- by sxthomson
I work for a great little software company which makes good revenue from our main software package. The problem for me is that it's almost unmaintainable. It's written in Delphi 7 (has upgraded versions over time) and has been worked on by a lot of developers over the past 20 or so years.
The software lacks any meaningful architecture - there's no object orientation whatsoever, horrible amounts of cyclical dependencies and an over-reliance on global variables to name just a few things. Another huge thing for me is Delphi 7 does NOT support 64-bit.
The problem here for me is that my management team don't care about technical things, they want to know why they should care. Obviously that's expected, so what I'm asking here is for some guidance, or tales, or pitfalls about this kind of thing.
There's a few things I would love to include, namely for me, the length of time taken to debug/write a feature in "legacy" code, versus coherent, well structured OO code. Does anyone know of any blog posts or the like where this is talked about? For us in the company this is a huge reason. Despite being decent developers we feel like writing a new feature is just piling more rubbish on top. On top of that, even for me who has a decent level of understanding of the code, changing things is infuriating - a small change can have a ridiculous domino effect.
Anyone have any experiences they'd like to share?
