I have been pondering the question about how much process do you need for a very small team, perhaps consisting of a single person, when developing software. There are a lot of good models and processes available for larger teams that address issues around delivery, productivity, quality and security for software. But how much of this should apply to a small team, or taken to an extreme, to a team of 1?
For example, paired programming gets a bit difficult when there isn’t a “pair” to start with. A single developer, working on some project on their own, doesn’t necessarily have someone they can work with side-by-side on a regular basis. Unless they choose to make their project or product open source, they won’t have someone there to review their code from a quality, maintainability or security point of view. Even making it open source doesn’t guarantee anyone else will look at the code, or even use it (witness all of the dead-end projects in SourceForge). They won’t have a dedicated QA resource to rigorously and formally test their work prior to release to some kind of customer. The solo developer can end up having to try to do it all themselves, but to be frank, very few developers are also capable testers or self-reviewers. They are human, and can have a hard time stepping back from their work, and view it with a critical eye. They may also not have the training or experience to be able to review from the point of view of security or general quality.
This can, and does, result in a lot of smaller products with questionable quality. I believe the iTunes App Store offers a collection of many examples of products, built largely by a single person, that suffer from quality, security and support/maintenance issues because many solo developers will simply code it and ship it. But, even for the solo developer, it doesn’t have to be this way.
For a solo developer, I believe there is some key infrastructure, as well as some simple processes, they need to improve their products. At a minimum, even a solo developer should do the following:
- Use some kind of source code control and management system. Subversion, CVS or even SCCS would be better than nothing. It allows you to keep track of changes to the code, and backout changes if the check-ins are discrete functional pieces. I would recommend something more sophisticated than “backup the code before the next change” and keeping the changes in an archive file. I tried that once, as was I was not satisfied with the result. The biggest issue: there was no meaningful record of why a change was made, and no record of why a change got backed out.
- Have a system or process for recording defects and new feature ideas for the product. This doesn’t have to be something elaborate, but setting up your own Bugzilla or Jira for your own use isn’t overly difficult. Just using an Excel spreadsheet would be an improvement. At a minimum, keep track of the date the bug or feature was reported/requested, and develop some kind of severity classification to assign to each one. Even in small projects, it is useful to be able to identify “hot spots” around problems or feature requests. It is also helpful to be able to understand “why” you had to do something to your product.
- When recording problems on GUI components, don’t just record functional defects like crashes or data corruption. You also need to keep track of problems around usability. It isn’t unusual for a small number of people to have problems using a piece of software, but if you start to see a trend, it may be time to rethink how elements of the GUI work.
- Use static analysis tools and unit test frameworks. There are free versions available for some platforms (JUnit and FindBugs are free for Java, for example). If you can’t find a unit test framework, consider building your own for your platform.
- Have a test plan for your product that tests beyond the unit tests, write that plan down, update it, and follow it. It is also worthwhile to look at what kind of training is available. Learn to be your own tester if you can. Alternatively, recruit help. You may find colleagues who, for the price of lunch, are willing to do some testing for you from time to time.
- Follow a simple continuous develop, test and review process, going in shorter sprints, like that advocated in XP. Don’t go away and code for days and days, or weeks and weeks, without stepping back and testing your work, reviewing what you’ve done and rethinking elements when necessary.
Depending on your product and technology platform, you may also want to look into some kind of continuous build system. For some products, that can be overkill. Your continuous build may simply be you building the product as a product, packaging it the same way it goes out to the customers, as part of a regular routine. However you do it, avoid having your test of the final customer package only be done the day you intend to ship.
I can anticipate some resistance to this from many solo developers. I can see why someone would ask: isn’t all that overkill? Doesn’t in slow things down? Won’t it get in the way of my “creative process”? The reality is that this will, in some ways, slow you down. However, I don’t believe it will slow your overall process enough down enough that you feel bogged down by the process. What I think this does is it helps you get a better product out the door, one that requires less of your time and effort dealing with maintenance and defects. Good carpenters measure twice and cut once. Think of this as a way to “measure twice and cut once” on your work. I also don’t think this will hamper your creativity. We’re not talking about spending more time on process than you do on the “fun parts”. What we are talking about is taking that creativity, and enhancing it to make sure your product will work.
The other aspect about this is that, in some cases, software projects grow beyond a solo developer. If your intention is to grow a product into something with a large customer base, that means you will likely need to grow beyond a solo effort and start to employ a team of some kind. If you already have a starting point for your processes, and something to build on, you will be ahead of the game. Your first new team members will at least have something to follow when they get going. You can expect that your processes, and the infrastructure behind them, will change. But at least you won’t be starting from scratch.
I know there are solo developers out there that don’t follow any sort of formal (or semi-formal) process, and do have high-quality products. I would submit that those are the exception, and not the rule. I believe that some kind of process, even a very lightweight one, will increase the probability of a better product for the solo developer.