Well since I designed the code while I wrote it some of the most important parts did not fully work with each other since I did not plan out their interaction fully.

I have to admit I find this difficult to believe. Why did you need to plan out their interaction? If you coded their interaction for one thing, and it didn't work properly, then that's not a planning issue, it's a coding issue. So why would it be any different for other interactions?

If you need to add another interaction, and the previous code doesn't fully allow that, then rewrite the previous code to continue doing what it used to do, whilst also allowing what you now need to. This is the essence of refactoring.

Also I have about 4 pairs of subs where the diffirence between the pair is in one symbol(+ or -)! I figured this code is beyond saving anyway

Not at all. The standard way of dealing with these pairings (say sub do_a and sub do_b) is to create sub do_c which is the 'more correct' version that will cope with both versions, taking whatever parameters you need to supply to ensure it does the right thing.

Then, once that is tested, you change sub do_a and sub do_b to delegate to sub do_c in the correct manner.

Then, once you've tested this, you can step through the remainder of your codebase, either now or over any period of time you like, changing all instances of do_a and do_b to the relevant do_c calls.

When you think you've them all cleared out you can change do_a and do_b to issue warnings, or even die, if they get called, just to make sure, and eventually remove the subs.

The speed at which all this can happen depends on the size of your codebase and the time you've got to do all the tidying up after yourself. But stages 1 and 2 are fairly straightforward, and they're all that are required to ensure that your code still runs correctly. Everything after that is just tidying up.

Sometimes it's definitely good to start from scratch ("build one to throw away", and all that), but there's very little code that's beyond saving, and the skills you can develop through saving unsaveable code can come in handy when you need to maintain code that you can't just start again from scatch!

Tony