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.

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 :-)

I use my Moleskin and Microsoft excel.

moleskin because its portable and I can read it on the go. i also use it as a diary.

microsoft excel because I can use it to track my project completion. i simply create a table listing all the TODOs and then add a column with project status (Not Started, In progress, completed, Deferred To next Iteration) and simply run totals on this field.

So far that has helped me stay on track. I can overcome my natural pride and let the data guide the development process.

On windows, i also use MS robocopy scripts to archive my code folders at regular intervals. (I have not fully mastered Subversion), there are tutorials for that online.

I work module by module too. i dont take the project as a whole but work with each section as a mini-application and use the above practices too.

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.

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 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.

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.

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

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.

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.