@BertMcMahan wrote:
If you can get funding to rewrite it from scratch (and you feel comfortable doing so!) then it MAY be the way to go. Couldn't say without seeing your code.
That said, if it's bad-but-working, then you have some tactics you can try. We have an old program like that around here. It was written in, I think, LV5 (!) and has been incrementally updated for 15+ years. Unfortunately, since it *does* actually work, there's never a budget for a full rewrite.
My tactic for this has been a very slow piecemeal approach. When someone asks for a new feature, I estimate how long I think it'll take, then double or triple it, depending on the complexity of the new feature. With a program like that, it's *very* tricky to update.
If I can get approval, I'll implement the new feature first, but if I have time left over in the allotted budget I'll fix or refactor something else while I'm in there. If I end up needing all of the estimated time, then that's fine too as I added a reasonable buffer for my estimate.
Over the years, the program has been slowly but steadily morphing into something SLIGHTLY less horrible to debug and use. It still needs a rewrite, but lots of things have been updated under the hood that really help make it work better.
That's not a bad idea, I think I could work it like that.
This is pretty much my scenario. The software does *work* but, yeah.
