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.

At my work, typically the developers here all work separately, we may share projects but often only do so when another isn't working on it (for reference, we're a consulting company. So someone may work on project A one month, then three months late, I may too).

What methodologies can we use to improve the quality of the code we produce when there is typically only one developer (at most three) on the project?

share|improve this question
Note: I'm not the only developer in the office, I can, if needed, pull more developers onto a project, or have them do something like ChrisF suggested such as code reviews. –  Malfist Mar 28 '11 at 20:41
Meh. I thought it was going to be a dating question. –  Andrew Grimm Mar 29 '11 at 2:55
@Andrew "HOT SINGLE DEVELOPER LOOKING FOR SOMEONE TO Sleep() WITH." –  Maxpm Mar 29 '11 at 4:11
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
I tend to develop wishing I had at least one other competent developer to work with. –  ChaosPandion Apr 1 '11 at 18:11
show 3 more comments

9 Answers

up vote 9 down vote accepted

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

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

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


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

Test-first and agile or lean, and for small teams XP.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.