My boss was clearly torqued about my email. He didn’t like what I’d had to say, much less that I said it to everyone on the project.

I had been asked to take charge of a project that had gone off the rails and get it back into shape. This is a role I had played several times before and was quite frankly pretty good at it, so I wasn’t too worried. Until I saw the code. It was an absolute mess. There were four (4!) separate data access layers used for the same data, the functional boundaries of many of the classes were blurred to the point where there was no coherency, and abstraction liberally applied to the point of absurdity. To make matters worse, the product had competing and contradictory functional goals that guaranteed it would fall short of doing anything well. Bringing me in to get everyone focused would only help us push this crap out the door, not make it smell nice. Hence my email suggesting we throw the whole thing out and redesign and rewrite the product from scratch.

I was with this company for nine years and had learned the hard way that completed code and designs were treated with an almost sacred reverence. Talk of rewrites, or worse, walking away from a product that was nearly complete even if it was obviously terrible, was tantamount to heresy. I confess to being an unabashed software heretic.

Two Different Kinds of Throwing it Away

My wife and I had many discussions about how we wanted to run things before deciding to strike out on our own. Many of the items that made it onto our list were based on mistakes made by our employer (we both worked for the same company). Near the top was to aggressively throw away things that just weren’t working, something we’ve since practiced with almost monastic devotion.

To give an example: We were nearing the end of development for Home Inventory 2 in the early summer of 2009 and although technically the app was fine, the user interface didn’t feel right. It was essentially a prettier version of the previous interface and didn’t fit well with some of the new features. Instead of trying to tweak things into place, we took the drastic approach of throwing out the entire codebase and starting from scratch with a re-imaged UI paradigm that gave us much more flexibility. The improved UI led to other features that would not have been possible (or at least very usable) with the previous UI. It took almost nine months of additional development before we were able to release it, but this rewrite of Home Inventory ultimately became the product that sold well enough for us to make a living as independent software developers.

Sometimes we return to the drawing board with axe in hand and turn the whole thing into digital kindling. We did this most recently on a project when it became obvious people weren’t grasping the concept when we tried to explain it. To make matters worse, they still didn’t get it when we showed them working development builds. Either is bad, but both together signal almost certain doom. Rather than waste a couple of more months on development and spend money on trying to market a probable dud, we decided it was better to trash it and move on.

Releasing Anyway

If something’s almost done, why kill it? Why not just finish it and release it anyway? Maybe it’ll do better than you thought. Where’s the harm in that, right? We’ve asked ourselves these questions many times. The answer is threefold. First, we want to be a customer-centric company and releasing software we don’t think will attract enough customers to make it financially viable means ultimately having to abandon those few that did find the application appealing. Every project is at risk of being a flop,  but why string people along when you are almost certain something has no future? It just doesn’t seem right.

The second reason has to do with resources. We are a small company with very limited resources. While it may only take a few weeks to finish a project we’ve fallen out of love with it is better to spend that time on something we really believe in. And the effort doesn’t just end with coding. You need to test it, create the product website/pages, come up with all of the promotional materials, market it, and support it. In the life of an indie developer every productive hour matters. You only have so many, so allocate them wisely.

Finally there is good old fashioned pride. Every thing we put out is a story about how we chose to spend some of our time on this Earth. Of course I want other people to like it (preferably a lot of them), but if I’m not happy with it, then it’s a failure as far as I’m concerned. How well something does in the marketplace is really secondary.

Go Ahead and Make Some Lemonade

Sometimes you have to try out an idea in order to find out if it has any merit. In science this is called an experiment. Often times many experiments are needed to reach a breakthrough. The same is true in the software development business. With rare exception, we have to try a lot of different ideas until we have something good enough that a meaningful number of people are willing to pay for. That big success will likely be built on a very solid foundation of little failures. Deciding to throw something away may seem wasteful, but if you approach it in a thoughtful manner you will get a lot more out of it than merely averting the release of a crappy product.

The obvious gain here is experience. You get to add to your “Lessons Learned” list, mostly on the what doesn’t work side, but it’s likely there are a few good things you can take with you to future projects as well. For our company these abandoned works have shaped the way we approach new releases. We are much more conscientious about determining the audience we are developing for and measure every feature, as well as the sum total of the entire app, against how well it serves their needs and if it does so in ways other products do not.

These projects have proven useful in other ways as well. Many times we’ve reached into the trash to pull out some of the code and repurposed it for something else. This was the case with a very serious productivity app that had the silly working title of Flinginator. Although it will never see the light of day, much of the UI and camera code found its way into an intentionally silly little app with an equally silly name, Looky, that did.

Remember the app I mentioned earlier that people didn’t get? We’ve gotten a lot of milage out of it. It’s where much of the code for the custom controls and other UI elements in Home Inventory 3 originated. We’re also working on an iOS 7 app based on just two of the oh-so-many features slated for the original app. We even plan on releasing it under the same name. That is unless we kill it first.