Anyone got any tips for organizing/managing a solo development effort?

Question

I've got a project I'm starting to tinker with that is a solo project but I'd like to try to stay organized and have some methodology to work from. Most methodologies that I've seen are aimed at teams. I'm wondering if anyone has any links or thoughts on planning/producing a project with a system as a solo developer. Thanks in advanced, John

Answer 1

Some ideas here

Answer 2

For me the most important thing to do is remain disciplined. So if you plan to do TDD, do it and don't get tempted to cut corners. Always try and imagine a future for your project where you will have more than just you developing the code - so make it readable and logical. Name variables appropriately, comment (if that's your thing) where necessary. Use source control and check-in as you would on a team project.

Also, keep business value in mind - don't waste your time on stuff that won't add overall value to your system. Assuming you are also the business owner, try and put on your different hats and see the project from both standpoints. I wouldn't go as far as suggesting you talk to yourself, but do keep in mind your techical and business goals.

So basically, do XP but without pairing :-)

Answer 3

A3, post-its, and a pen. ;-)

Answer 4

Never give up. Don't quit. Even when you think you can't do it by your self - don't quit. I built a 10 person company and for the first 18 months I worked all by my self. 3/4 of the code that was in the final product I had developed in that first 18 months. We got to our first 10 customers on that code. Don't quit.

Answer 5

Since you're tinkering on your project, tinker with organization and methodologies as well.

• Try a few version control systems until one feels right.
• Try a few issue tracking systems.
• Run with no formal project management for a while and then try something rigid.
• Do everything by hand and then try to automate everything you can - code generation, builds, and testing.

Find out what works best for you by trying everything. Experiment.

Answer 6

As one facet of your process I don't think you can go wrong with writing user stories. I speak from experience, very recent experience; in fact, just this week. I had written a bit of code for my first serious Ruby/Rails effort, a personal project: see http://stackoverflow.com/questions/1932986/how-to-make-my-first-ruby-effort-more-idiomatic/

After digesting the answers I got, and before writing any more code, I found myself writing little paragraphs of maybe a sentence or two. And in some cases a few bullet points, but interestingly, I didn't set out to write user stories. I just thought that by writing down various things I wanted to do with the project, I'd further clarify things brought to light by my initial coding, and feedback received.

After a few paragraphs, I realized I was creating user stories. Now that I have them, I've written some more code, and have checked a few things off my list.

Answer 7

Set up a home source code repository (I use perforce), and check in changes frequently. It's tempting not to do this when you work alone, but even when you aren't worried about contention for source files, having a record of where you have been can be valuable.

Having the goal of getting to a checkin point every day will also help you to create micro-goals, which in turn will help you think about how you break the problem up into bite sized pieces.

Answer 8

plan some, then work some

always know what the next step is, and focus on that

keep a log/journal of what you did and why, including design decisions, so you don't go 'round in circles

Answer 9

Being a one-man web-design studio I use a Basecamp free account to organize to-do lists (a nice thing their tasks have comments, so when you solve some task you can comment it step by step for further reference). Messages and milestones are useful also. To keep track of the code (php, html, etc) I use Eclipse and its built-in CVS.

Note: I tried various project managers and version control systems, but all of them seem to be too functional for a single developer.

Answer 10

I find it useful to follow TDD (Test Driven Development) and always end a development session with a couple of failed tests. When I return to the project (which might only be after a couple of days) I have a logical starting point. This helps me get into the groove quicker rather than staring at my IDE for 2 hours.