Indie Software Development - You Need A Process

Process sucks. It slows you down.
Process rocks. It speeds up development.

It's a problem developers face all the time; how much process is enough? As a full-time industry developer working on large software systems with teams ranging from 10-500, process is important. Process helps you:

• communicate
  
• plan
  
• deliver quality software
  

As an indie developer though, how does process help? First off perform the Joel Test: 12 Steps to Better Code. Joel's test is as important to any indie developer, even a one man shop, as it is to a large organization.

Crazy you say! One developer does not need a process!

Do you want to ship?

If the answer is yes, then you need a process.

I use process to help me:

• keep track of what I need to do
  
• tell me when I am done (when my original list of features is done)
  
• help me deliver quality code
  
• help me estimate future projects better
  

As a one man shop, I sometimes skipped process and it bites me. I then end up wasting time on rethinking what I have to get done.

On the other hand, when I follow my process I quickly know what I need to do. That said, I have adapted my process as I've learnt what works best. Here is what works best for me:

• Source Control: git, it's free, it's easy, it's fast, I like it. I've heard complaints but so far it has served me well.
  
• Specs: What am I building? I write Use Cases, sketch UI mockups, write a feature list, and I work out how the system will be implemented (web services, data structures, and data interfaces).
  
• Bug Tracking: I use FogBugz; if you are a student or startup (2 people or less, like me) then you can use FogBugz for Free
  
• Schedule: See previous for FogBugz
  
• Functional Testing: I do it myself with a mix of unit testing, frequent code+test iterations of each new feature, and I solicit Beta-Testers to get feedback on devices/OS configurations I do not have. This is something I want to spend more time on to get a better balance of unit tests to ad-hoc testing. Currently I am doing more ad-hoc than unit tests and it bites me with wasted time.
  
• Usability Testing: I show the app to lots of people, iPhone/Touch owners and non owners to get feedback on the UI. Is it intuitive? Is it fast? Does anything jump out at the user as bad/ugly/hard to use?
  
• Bugs: Log them when I find them and fix them ASAP. I log them so that I can review what I have in my bug list before I move onto other code. I try to keep true to the rules of "Fix the First Problem First" and "Fix It When You Find It". This helps me stay focused on my task so I am not trying to work around things I know are broken. This wastes brain power.
  

That's my main process for a one man shop. It is how I keep things straight with only 1-3 hours/day to work on my projects. Working in small units of time means being efficient and coming up with ways to keep track of tasks that are usually in a mid-completed state.

As for how I manage to complete features that are larger than 1-3hrs, I use the tried and true technique of breaking the problem down. Basically:

• Break features into smaller features.
  
• Work on one feature at a time.
  
• Test when feature is implemented.
  
• Commit feature.
  
• Rinse and repeat.
  

This works for me and let's me work on something that might take 10-15 hours of research, design, code, and test over several days. Without the frequent code/test/commit cycle I run into trouble trying to implement multiple features at one time, or trying to implement one large feature that could have been broken into many smaller features.

KISS (Keep It Simple Stupid) works for software development as well.