How to lose traction on a personal software project

So you’ve started writing your first program — great stuff! Here are a few tips and traps to watch out for along the way.

Long periods of time when your program doesn’t compile and/or run at all

You enthusiastically start work on some big changes (e.g. re-architecting your application), but stop because you hit a brick wall, or don’t have the time to finish it. The source code is left in a crippled and unfinished state. You can’t do anything with any of your code until this is fixed, and the longer you leave it, the more you’ll forget and the harder it will be to get started again.

In Continuous Integration this is called a broken build, and is a big no-no because it impacts other peoples ability to work. Without the pressure of a team environment pushing you forward, having a roadblock like this in your path makes it very easy to lose faith and motivation.

Make massive changes on a whim without revision control or a backup

There’s nothing worse than changing your mind about the design of something after you’ve already thrown away the old one. When you do something that involves changing or deleting existing code, be sure to make some sort of backup in case things don’t work out.

If you haven’t taken the plunge with revision control yet, I highly recommend looking at some of the free SVN or GIT hosting services out there e.g. GitHub or BitBucket — once you get into it, you’ll never look back.

Ignore the YAGNI principle and focus on the fun/easy bits

Focusing on things like validation, eye candy or even general purpose ‘utility’ functions is a great way to build up a large complex code base that doesn’t do anything useful yet. Focus on the core functionality of your software first — your main features should be complete before you start thinking about nice-to-haves.

Throw your code away and start from scratch

As Netscape famously discovered a few years ago, throwing away existing code to start afresh is almost never a good idea. Resist the urge and make a series of small, manageable code refactorings instead.

Start programming before you have a clear goal in mind

Instead of a command line tool, maybe my application would be better as a simple GUI application? Or, I was originally writing my homebrew game for my old Xbox360, but now that we’ve bought a Wii, I’ll port it to that instead!

What are you actually trying to achieve? Spend some time with a pen and some paper coming up with a really clear vision of what you’re trying to create — e.g. screen mock-ups. If you don’t know what you’re writing from the start, the goal posts will keep moving as you change your mind, and you’ll have no chance of finishing it.

Get carried away with project hype before you’ve actually got anything to show for yourself

Spending hours trying to think of the perfect name for your software, designing an icon, choosing the perfect open-source license and making a website won’t get you any closer to having a working application. Get something up and running first, and worry about telling people about it later.

Start a million new features and don’t finish any of them

Jumping from one idea to another without finishing anything is like spinning a car’s wheels and not going anywhere. Make a list of features your program should have, and put them in order of most-to-least important. Work on them, one-at-a-time, in that order.

16 thoughts on “How to lose traction on a personal software project

  1. Great post!

    For the past few days I have been thinking of ditching my current code base, which works fine but is a mess – cobbled together from various open source projects and hacked together with php – and re-writing from scratch on something like the Zend framework.

    And yeh I can relate to that first item as well – I have had countless times where I just cannot bring myself to return to a project that I have left in a broken state.. its just so hard to get over that mental jump you need to get in and fix something you know is not working..

  2. Having self imposed deadlines also helps a lot.I usually have a dev cycle from one weekend to another. So, I come up with ~6 features which I have to implement, of which I end up implementing atleast 4 or so. The remaining features are carried forward to the next week.

  3. Good post! You never treat your private projects the same way as work. This might be a great freedom, but it can also get you in all sorts of trouble. I’m trying to start making pet projects for professional to try and avoid these kind of issues.

  4. not limited to personal projects

    this could be an accurate summary of many projects in software companies i’ve worked at, and btw, you’d recognize the company and product names!

  5. Heh. After committing 3, 4 became a psychological necessity. I startwed working on a PBeM game (Yes.) and first thing I started writing was elaborate set of classes for general-purpose PBeM game client server with many features. Upon nearly finishing it, I got bored and gave up for half a year I think… Only after shift-deleting the code to get rid of psychological burden I was able to start slowwwly coding again, this time game first :)

  6. Great tips, might want to add once you know what you’re going to do and know how to do it, design first. It’s far easier to code around design than design around code if you’re a programmer.

  7. Hey Richard,
    The link to “” looks like it’s broken.

Comments are closed.