Trash Can part 1

Use it. A lot.

When building new software products — or even trying to add capabilities to old ones — teams (and by that I mean management) are averse to throwing code away. But they shouldn’t-in fact sometimes it makes more sense to throw something away than to try to continue to work with it.

We’ve likely all had this experience — you’re working on something important and you’ve spent a lot to invest in it. Then a few days before its due — you lose it completely. This happened to me twice in my student days (long before today’s source control tools). I was able to meet my deadline with something completely new from the ground up — and, frankly, it was better than what I had lost.

Why is this? The majority of the work put in to the original version was a combination of experimentation and learn-as-you-go. I made mistakes but I didn’t realize them until later. Confronted with a complete loss my only option was to start over. But to my amazement I completed the whole thing in a handful of days with a better, more organized and well structured result.

Since then I have been happy to use the trash can. Its a great tool for cleaning up products and it lowers technical debt over time.

Part 2 will explore using the trash can when maintaining long standing products with older code bases…

In case you are interested the projects I lost were an electronic drum machine and solution for evolving source code to solve optimization problems using Genetic Algorithms. I did that in Modula 2. That’s how old I am.