Hi All,

I spend a lot of time working on projects in which I am the sole developer, project manager, designer, QT person (Yes, I know... Bad!), and sometimes I'm even the client.

I've tried just about everything for planning projects and managing myself, from just sitting and working freestyle until the project is done however long it takes, to a single-person version of scrum in which I held a progress meeting with myself over a one-man burn down chart every morning (not kidding).

For those of you who spend much time working alone, what is the best way to organize yourself, manage large (for one person) projects, and keep productivity as high as possible?

11 accepted

Keeping a clear list of your goals is vital. It's easy for feature creep to take over a self-managed project. The TDD "it's done when it works" approach is helpful as well. This prevents you from becoming a perfectionist.

One thing that really helps me is to imagine what another engineer or a project manager would say in any given situation. Often I'm able to "shame myself" out of bad code, or get back on track if the schedule is slipping.


i wish i could say i was able to practice what i preach 100% of the time, but BDD seems to be a good approach to take in your situation:

Here's a link with more info: http://en.wikipedia.org/wiki/Behavior_driven_development


Here you go... http://xp.c2.com/ExtremeProgrammingForOne.html


I'm in a very similar boat. I try to follow agile principles (as well as I understand them) as much as possible. I'm probably not doing things "correctly", but I've had great success on my projects by trying to follow agile principles. It takes an enormous amount of discipline, since there's no team to make sure you don't just start taking shortcuts.


I've rolled my own version of agile that relies on stories, heavy customer interaction, frequent releases, and test-driven development. I use a wiki to track stories, get the customer involved as much as possible in writing them, and have the customer work with me to prioritize and organize into releases. I use TDD to drive the design and implement. I set up a QA server where the customer can try out frequent releases (sometimes daily as new features are developed) so that I get feedback quickly. I rarely go more than 3 iterations without a release to QA. Customer gets to decide when the QA version has enough features to go live -- and if no more features off the list need to be developed.


If it's throw away code might be able to be a little loosey-goosey with methodologies, but anything important and I'd say your way of treating it as team project with one person is very nice and disciplined.

Write your code for the next guy to read, not you...be nice to him/her. Even the "throw away" code stays around forever.


Some people just need to be managed, like me. Actually not quite true, I rather like to be managed so I can concentrate on my job.


I suggest you the following:

  1. Test-Driven development
  2. Eavy use of "TODO: note here" in your code when you see something you are not able to do immediately, and come back to them when you have time instead to stay on facebook waiting for your client to call back
  3. Write your code as your client will buy it looking at the code not at only the result, imagine your client as the chairman for a code review.
  4. Fill your code of asserts