where sometimes good projects go to rest

The Project Graveyard: Where Software Goes To Die

Written by

Walter G.

Published on

July 15 2014

Modified on

May 24 2016

Filed under

Tech

Every developer I know has one thing in common. It's not a great thing, but it goes with the territory. I came to accept it and learn what I can from it. What is this magical thing? Dozens to hundreds of started projects that were never completed lying dormant in our hard-drives. Personally, looking at my projects directory at this moment, I have 115 projects total, and only about 10 are actual websites that are completed. The rest are alien to me. Vague names give me an idea of what I was thinking at the time, but not much else. I'm sure 5 years ago, these ideas seemed like gold to me. Today however, they are a remnant at how much code one is capable of writing. And I'm not saying these are all bad ideas. Some still sound like they would be good products to build, but for some reason they were left abandoned long ago. Let's dive into a few of these reasons, while I recant about my not so awesome moments.

We Get Bored Sometimes

Sometimes a good idea you just had, turns out to be a really dull and un-impressive concept a week later, or an hour later. Happens in everyday life to everyone. If you're a software developer, that usually means starting a project, working on it for a few days (hopefully) and then getting a "better" idea to work on and moving on. The consequences here are that you might of just abandoned a really good idea. Just because it was boring to build, does not mean that it isn't useful to some market out there. Sometimes code is just boring to write. You outline the process in your head, and the first half of development hours need to go to acquiring and cleaning up data. If you can make it through that hurdle, say hello to your brand new application. If not, then time to add another name to the list.

I'll say this, boring work comes with the territory. If we gave up whenever we got bored then nothing would ever get done. It's one of those things that just need to be done. If it's something that's just too boring, break it up into smaller pieces and do it incrementally in between other boring work.

So Maybe This Is A Terrible Idea

Sometimes, you just really have a bad idea. You think it up, think your Tesla, draw it out, really believe your Tesla, and start building it. Later on your friends question your sanity at the idea. It happens. There are no bad ideas. Except for those. Those are the definition. There's been more than a few of my ideas where I awoke the next day and contemplated changing career. Someone once said that success is a long series of failures, and it's going to take many many bad ideas, before one is actually gold.

---

I had this idea a while back, and in my head it was amazing. The plan was for a mobile game that would show the user equations and the user had to fill in the missing variables, with the type of math problems getting more complex as the levels increased. Even writing this down, it doesn't sound that bad. Then I implemented a small version on my browser as the final proof of concept. Afterwards I realized that I had wasted 2 days building a proof of concept. After showing several people the project, with less than lackluster reactions, I moved on. Turns out that this isn't fun:

---

This was possibly the worst idea I've ever had. I'm not a fan of pop music and now I have to write pop news every day in order to hopefully get traffic and get some ad impressions in. This project lasted probably 3 weeks of content gathering and dev time and another month before I decided that had lost my mind. I found both boring to work on and it was also a really really bad idea. These kind of ideas come and go, and I learned my lesson. If an idea sounds stupid before you start, it probably is.

Abandoning projects is part of the development life cycle. It's a frustrating part, but one that everyone will deal with at some point. I built that small game and realized it was boring and had almost no replay value, unless you really enjoy basic arithmetic. It's a dead project for now, but maybe at some point down the line it can be revived as something totally different. The good part about writing code is that it's never a waste. It just adds new functions that you can later use some point down the line in some other project.

Acceptance

You wasted some time, maybe learned something along the way, and now you're ready to move on in life. Dead projects are a part of life and come with the territory if you're software developer. Specifications change, times change, you change. It's inevitable. You add that project directory to a isolated and not in the way place and get started on the next possibly dead idea. This step is the hardest to do. You just spent 2 weeks writing code, slowly getting less and less enthusiastic about the idea, and now you have to scrap the idea all together.

Zombie Projects

It's dangerous to go alone. Sometimes these projects just don't stay down and they end up back in bizarre incarnations of what they once were. Half the code might not be used, and it might look and behave 100% different than what was first planned. Never discard that code 100%. Keep it backed up on a spare flash drive somewhere just in case 2 years later it makes total sense to create.

One Solution

Many projects are doomed from the start. Without realizing it you spend hours upon hours working on them wondering if it makes sense. We can cut that time down considerably by taking a different programmatic approach. By developing using the RAD (Rapid Application Development) model you can cut down the time you spent modeling and designing significantly and get an idea of the projects final form much faster. The last few projects that I've started work on have gone much much smoother because I started to adopt the rapid development approach. With personal projects it's much easier, since there's no overhead of 4 different managers.

With the RAD methodology, you develop quickly and gather specs and make choices as new information is revealed and brought into the system. I build a laptop search tool using this approach and it came together in under 1 day. A few hours in the morning went to drawing up a very simple layout and essentially what the site was about. Soon after, the coding began. Around 10 hours later a working version was complete, and it was awesome. It was almost a 1 to 1 with my initial design, and it made sense from a usability standpoint. The following days after went to debugging and data gathering, which comes with the territory. At most, if it had been a bad idea only a few hours of my time would of been wasted.

Comments

No messages posted yet

Add comment