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:
- deliver quality software
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
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.
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.
KISS (Keep It Simple Stupid) works for software development as well.