The software death cycle

Software death-cycle is not a new term, but most people use it in a way that implies a problem with a given project's adherence to the software life-cycle, a project which is launched but quickly becomes obsolete or perhaps is unusable to begin with.

The software death cycle I'm talking about happens long before a project is launched, and has nothing to do with adherence to the software life cycle. Specifically, I'm referring to projects that fall to the back-burner, either because other more exciting projects come about or because the project simply became less interesting as time went on.

Whatever the reason, when a project dies before it's even launched, there are a significant amount of man-hours lost. Perhaps some experience is gained, but it typically doesn't outweigh the amount of hours flushed when a project is abandoned.

Why projects are abandoned

Before we try to solve the problem of abandoned projects, let's identify a few reasons why it happens in the first place:

A more time-sensitive, exciting or lucrative project comes along
The project became less interesting or challenging
The project hit a long stretch of grunt work
The project ran into a technical snag which was difficult to solve
The scope of the project ended up being much larger than originally anticipated

A new project comes along

It's understandable that a new project would take priority over a project already in the works. However, depending on the size of the project, putting all efforts towards the new project essentially forces the current project to the shelf to collect dust. But no problem, right? We'll just pick up where we left off when this project is completed. If you've ever tried doing this, you know it's not as easy as it sounds. When a project sits on the shelf, the following things can happen:

The inner workings are forgotten.
You didn't have a solid project specification or your code isn't well documented on a high level. These are important, but get overlooked, especially in single-developer projects. Most of my projects are single-developer (myself), so when I feel the heat of another project coming around the corner, I typically go back and write a quick paragraph of comments in each major class or template – kind of a "Hey, remember this" note to myself.
New technologies or software emerges, making much of the code obsolete.
I develop an entire application based on jQuery 1.7, then need to let it sit for a couple months while I work on a different project. By then, jQuery 1.9 comes out and I'm using it full force. I really don't have a big interest in coming back to my jQuery 1.7 project and unlearning all my new tricks.

The solution to this problem is to review the documentation of the newer version of the library you're using. Check the list of features that were removed since the older version, then use your IDE's file search tool to locate any occurrences of those deprecated features and replace them with their newer counterparts.
The person who formerly managed the project is no longer around.
You'll need to contact the former developer of the project, so he or she can get you up to speed. Trying to wrap your head around everything without a high-level overview will be difficult. Also, you may miss some of the nuances which are not well documented. Ask for a functional specification, or if possible, compensate the person as a freelancer to oversee the completion of the project.
The code is well documented, but the developers can't recall what was required to bring the project to completion.
This is another one that requires a little pre-emptive work on your part. It's actually a lot easier than going back and documenting the code, post-development. What I do is, before starting on the next project, quickly draw up a list of all of the features that were currently in development (include filenames & line numbers if it helps). I also make a separate list of all the features that have not been started yet, but are required for the finished product.

One great way to do this is to use BaseCamp or another project management tool. Create a new project, then a drop in a bunch of to-do items. This serves the alternate purpose of reminding you later that this project has not gone away, there are still active to-dos on the list!

Loss of Interest

This problem is compounded when it's a personal project, as there's no immediate financial motivation to keep the ball moving. In the past, I've taken one of two approaches to work through this problem:

Make the project more interesting
This could be as simple as slapping a design on it. Many times I find myself working out the internals of a project, looking at nothing but a "data dump". Putting a simple design on the application breathes a little bit of life into it.

If that isn't the way to go, try applying a new methodology. For instance, if you were taking a procedural approach, try sprinkling in a little objected-oriented code. This is typically not a good practice, as it breaks down the consistency of your code, but anything is better than watching your project become dust in the wind due to lack of interest.
Force yourself to devote time to it
This is important, if you spend too much time away from the project, you'll lose your mental grasp on it. By spending just a few minutes a day to, say, write a basic routine or create some pseudo-code, you maintain just enough involvement to maintain your understanding of the code.

Danger, grunt work ahead

This bears some similarity to the issue mentioned above, the project becomes less interesting, except that you typically know in advance that there will be some grunt work. But, the time comes where the brain drain has to happen, and instead of pushing through it, you move on to a more interesting project.

You typically have three options when it comes to the mind-numbing, data-entry-like work that's required to complete your project:

Outsource it
Elance might be a good place to find low-cost work that doesn't require detailed knowledge of the inner working of your application.
Automate it
Many times, writing a script to automate the data entry task is both a time-saver, as well as an interesting task in it's own right.
Do it
As mentioned above, set aside a few minutes each day to plug in the data manually.

Technical snag – pause, don't stop!

I don't think the term snag is appropriately used, but that's the term everyone understands. To me, a snag is something that stops you in your tracks, but also destroys whatever got snagged. Your keyboard does not rip or tear when you hit a technical snag. How about glue? I got stuck in some techno-glue!

Regardless of the term, there are typically two reasons you walk away from a project when you get stuck:

To clear your head so you can return at a later time using a different approach.
This is acceptable, and probably recommended.
You don't want to deal with the issue, so you put the project aside.
This, of course, is bad news. The problem is compounded as time goes on and you forget about the details surrounding the issue. If you absolutely can't spend any more time to resolve the issue in the foreseeable future, you need to document it. I personally like to drop in a highly emphasized comment in my index file, default method, main controller, or whatever your application considers to be it's point of entry. For example:
/* !!!! ISSUE !!!! load.php - line 242 - Can't figure out why a FileNotFound error happens whenever I try to load the config file. This needs to be fixed before further testing can be done on app initialization. */

Scope bloat

Scope bloat sounds disgusting, but scope expansion isn't near as memorable. I like to think of it as what happens when you open up one of those memory foam cushions, then a week later it's the size of your living room. You may have made accommodations based on it's shipping dimensions but didn't dig deep enough to find it's dimensions when fully expanded.

The same thing happens when you don't write up a technical specification for your application. If you come up with a mental model, you may think you've covered all the bases, and certain components may seem simpler than they actually are. You're doing yourself a big favor by spending even an hour laying out all of the major classes that you consider necessary in your project. Then, if you have time, detail the public methods and properties that the major classes will contain. This will help you conceptualize how the classes will work together. I personally want to get started coding a project just as quickly as the next guy, so I understand the hurry. For that reason, I know it makes more sense to be realistic about the planning phase. A single developer working on a small project simply does not want to waste too much time on a technical or functional spec. But, you should at least get something down on paper, you'll be amazed at what you reveal, and how much you actually learn about the true scope of your project.

Additional Tips

Keep a running list of your projects somewhere, BaseCamp, or any other project management tool. You really want to make sure none of your projects are left behind – it's just wasted time.
Don't start a project without knowing what your plan is when it's finished. If your project is for other people to use, how will they learn about it? Do you have a plan to get the word out, and does your plan usually work? If you typically drop the ball in this phase, and end up with a whole bunch of great applications that nobody knows about, reconsider the time you spend on these projects.

Other things to consider before starting a new project

Does it add any value to your customer base or site visitors?
Will it make money for you? If not,
Will you enjoy the project?
If the project is purely for your own enjoyment, can you spare the time?
Are you pulling that time away from other projects or spending time with your friends and family?

Tags: project managment time management