I once got this “emergency” project where I had three weeks to deliver a mobile prototype application that was to be demonstrated at a major user conference. I spent the first week creating a UML design for the app – also looking for a back-end guy to build the Java API’s for me to call. Then spent a few days prototyping some assumptions and testing our JavaScript library’s capabilities on various phone-based browsers. Once I proved that out, I had roughly 7 business days – plus a weekend – to deliver the project.

Five days and almost 600 lines of code into implementation, I realized that I was doing a boatload of coding; way too much, writing lots of code that to address things that I hadn’t considered in my design. So I stopped coding, opened up my design, ran through the sequence diagrams and realized that what would’ve helped was having an intermediary object act as a ViewController and manage the various view objects. So went back to my class diagram, inserted the new object with the methods and properties that I expected it to have, re-worked my sequence diagrams then went back to my main JavaScript file and…

…completely erased it…

I mean, Select All -> Delete.

When I redid the code, I finished it with less than 50% of the original lines of code and actually checked it in with a day to spare. During testing, only cosmetic flaws were found, but no functional errors. I fixed those flaws and the prototype was released and demoed live at the conference in front of over 1000 people. The point to all this is that once I had the right design, the coding was absolutely simple and straight-forward. I wasn’t writing any compensatory code or dealing with deficiencies in my design because the design was right.

Moreover, erasing all my original work ensured that I wasn’t influenced by my old code. I had to start with a clean slate. But in the end, I still beat my deadline by a day.

Now, this isn’t something I recommend for huge projects, but as a rule of thumb, if you find that you’re writing a lot of code – especially with object-oriented JavaScript – chances are your design is flawed. At that point, stop, re-evaluate your design, and back up to a place in your code where you can adapt to the better design. Yes, sometimes that means getting rid of all of it, but most of the time, you can back up to a reasonable place without erasing all your code. But in either case, don’t be afraid to scrap code; especially if it means that the final product will be superior to what you originally created.