Less well known than many of the other methodologies in use junk-it and start again is one of the most powerful techniques available.
This only really works well at the beginning of a new project. Junk-it doesn’t work with existing tried and tested systems and applying that is completely the wrong approach and will probably almost sink the company (as it did with Netscape).
I’ve seen, and worked on, systems that have grown out of the wrong technology, usually by productionising a prototype. This doesn’t often work out well as you tend to end up with a productionised prototype.
You will often gain more time by throwing away something than trying to make it work, especially at the start. We don’t want to end up with something like the following (vastly simplified model of a genuinely bad system I had to work on), colours indicate seperate layers in the original design, or at least they were supposed to be different layers.
Application of the wrong technology
When I was 16, coding in 6502 assembler on a BBC Model B, I built a word processor called WordStyle. It was neat, efficient and compact, and largely good enough for my purposes. However it lacked a spell checker. I only had 12k of space left (from 16k) and having discovered checksums in someone else’s code I figured that this will allow me to get a comprehensive dictionary into 10k bytes. So I built it. It worked, or appeared to. I then discovered that it didn’t really work because certain garbage words would pass the check and then realised that checksums were simply not good enough. Charged with enthusiasm and an unshakeable self belief I continued and made a few refinements, choosing really to ignore the basic problem that it was simply a bad idea. It was only when a trusted friend pointed out that a spell checker that couldn’t reliably check spelling was in effect worse than useless that I had to admit defeat.
Use version control.
Any version control, except possible SourceSafe, is your friend when making any large changes. I don’t mean branching specifically, I mean the ability to start from a checked in version, make masses of changes, get it horribly wrong and then dump the changes as though they were contagious, which quite often bad code can be.
You’ve got to really junk-it.
If needs junking then do it properly, use Delete Permanently (or rm -rf). If you’re not quite that brave then put it on a USB stick first, but it has to go completely, to help you resist the temptation to refer back to it
Then redo it from scratch and memory. You will feel, or at least I do, that you are simply doing the same thing again; but when you’ve finished the second version will usually be much better than the first and you’ll thank yourself for it.
Disclaimer.
Don’t blame me if it all goes horribly wrong. Do take a backup. Do keep it safe. Do not expect power to remain on constantly and instead save changes regularly to a persistent medium. Note that printing does not count as a persistent medium in this case and unnecessary printing may destroy rain forests, cause ozone poising and occasionally cause the printer to set on fire. Do not work in badly ventilated areas. Do not attempt to balance wheely chairs on their back two casters, it will end in tears. Do not attempt to store DAT tapes above where full coffee mugs may be present, DAT tapes fit nicely into mugs. Do not insert damp or wet DAT tapes into a drive as it may require replacement of the tape and the drive.