Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

migrated from stackoverflow.com Mar 19 '11 at 2:19

This question came from our site for professional and enthusiast programmers.

marked as duplicate by maple_shaft yesterday

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Test-first and agile or lean, and for small teams XP. –  richard Mar 29 '11 at 12:13
    
@Richard, why not turn your comment into an answer? –  azheglov Mar 29 '11 at 13:17
13  
One thing we do is search. There are many, many questions on this topic. programmers.stackexchange.com/questions/50658/… for example. All of these. programmers.stackexchange.com/search?q=solo+programmer –  S.Lott Apr 1 '11 at 11:10
1  
I tend to develop wishing I had at least one other competent developer to work with. –  ChaosPandion Apr 1 '11 at 18:11
    
show 1 more comment

15 Answers

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.

share|improve this answer
    
The TDD approach is not "it's done when it works". The TDD approach is "it's done when it works and the code is clean" –  Benjamin Hodgson yesterday
add comment

Code reviews.

These are particularly useful as you'll be explaining the code to someone who hasn't worked on the same project so they won't have any of your assumptions about how it should work.

They'll also have the added benefit of sharing knowledge around the company so when someone else has to work on the project (due to people being busy elsewhere, off sick, having resigned or been fired) they'll not have to start from scratch.

share|improve this answer
add comment

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

XP scales down nicely since it is optimal for small focussed teams..

  • You can create a spreadsheet of feature requests, prioritize them & pick the top-most one.
  • define the acceptance criteria (what done looks like) and code it up into a executable test
  • Next define engineering tasks to get to done
  • Write unit tests, do the simplest thing (YAGNI) and refactor all the time. The goal is to make the outer acceptance test pass
  • Timebox each session. For effective time-management, you could also look at the Pomodoro technique.
  • Use version control & Setup a CI server / a batch file to create a install or zip of your software
  • Demo frequently. Route the feedback into the original spreadsheet and reprioritize

The only thing that you couldn't do in a team of one is PairProgramming.

share|improve this answer
add comment

At my company our group all works on the same project, but on relatively independent slices of it. One thing we do a lot around here is when something you're doing seems a little tricky, or you're at a fork in the road with more than one way to implement something, you grab someone else and discuss the pros and cons before you proceed. If you wait until you consider your code finished to do a review, you've usually already invested too much time to consider major architectural changes, although certainly a lot of defects are uncovered in code reviews.

Also, I realize Test Driven Development is a little buzzword saturated lately, but it can be a big help for solo developers because it provides a quality check as you go, and when tests become difficult to write you know you probably need some restructuring of your code. It also helps later maintainers to not accidentally break the code in hard to detect ways.

share|improve this answer
    
+1: TDD. Specification and API documentation in one tidy package. –  S.Lott Mar 28 '11 at 22:12
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

I find that using code formatting tools such as ReSharper ensure that, at least visually, the code is easy to pick up for other developers.

In terms of actual methodologies, it's difficult for a single developer to stick with any particular one. I am a consultant who generally works alone, and I find it the easiest for both myself and the client to use an agile process. I typically try to get my clients to directly enter their requirements into a tool such as Trac (or I will, on their behalf). This not only helps other developers identify the purpose of code, but also yourself 3 months down the line!

share|improve this answer
add comment

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
share|improve this answer
add comment

Any appropriate methodology will help - irrespective of the number of people on the project. So pick one at at time and see how you can apply and map to your domain, and measure their successes.

Perhaps more interesting is to ask, what methodologies not to throw away because there is only 1 person working on the project.

And the key one that stands out to me is Source Control ( Yes that is a tool, but it is part of your work flow, so also a process ). People might be tempted to give this is pass since they "don't need to support multiple people editing the code at the same time".

Ironically I find that a distribute version control solution like GIT is better for an individual that something like SVN.

share|improve this answer
add comment

philosophy: XP/TDD + GTD

general outline:

  • interview stakeholders
  • screen mockups, walkthroughs, paper prototypes (as necessary)
  • feature/story brainstorming (with and without stakeholders)
  • test-case brainstorming (with and without stakeholders)
  • overall design/architecture think-time (as necessary)
  • iteration planning (with stakeholders)
  • iterations
  • process review, training, maintenance planning, etc (as necessary)
share|improve this answer
    
I agree with all of that, and am really happy to see it as the first answer. But with a team of 1, I think kanban-style scheduling is even better (and even easier) than having iterations. –  William Pietri Apr 2 '11 at 3:42
    
@William if the client understands kanban, or there is no client, go for it –  Steven A. Lowe Apr 3 '11 at 1:19
add comment

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.

share|improve this answer
add comment

Agile

features, stories, and test cases are far more instructive than more formal documentation, and a set of working tests is better at demonstrating how to use something or how something works than any amount of dead trees

It is also easier to hand off work in between iterations.

share|improve this answer
add comment

As a consultant my self, I would suggest that you find a way for there always to be at least two developers on any assignment.

I agree with going agile, and on leaving an agile trace of stories and tests that others can follow, but I don't believe that or any other process or methodology will stick while people are working in solo.

share|improve this answer
add comment

I think Code reviews are a good start but I like it when its made informal and fun, like doing a Pair code review or pair programming in order to tackle a certain issue/problem or some enhancement (e.g. changing legacy code to meet new coding standards). At times two sets of eyes is better than one and its also fun, I feel that sharing and discussing seems more open. You could also have like formal/informal lunch and discuss sessions to talk about what you did individually or as a group e.g. mention about a new pattern you used or new technologies how a problem was solved?

share|improve this answer
add comment