Project Management: On Software Development Processes

For those of you who haven't been following the progres of CaseySoftware, we've had a great kickoff. We started approximately six months ago with one person parttime. After a month or so, we went up to one person fulltime, one person parttime. Just about every six weeks, we've grown by another person. It's been exciting, but it has required us to get more process in place faster than originally planned. I've also been reading Steve C McConnell's Software Project Survival Guide, so this has been on my mind more and more.

First, when developers only had a task or two on their plate at a time, task managment was simple. As things have grown, the required tracking and information needs have steadily grown. Conveniently enough, we had a wonderful tool called dotProject. Once the permissions were properly configured, it was relatively simple.

Next, since we are an entirely distributed team, communication is a top priority. While the forum system within dotProject is useful and email would work, we have decided to go with phpBB to ensure that we have a complete history of discussion which happens to be searchable.

Next, one of the team members is now working on drafting coding standards and evaluating tools to enforce them. We're beginning from the PEAR standards, but we'll likely grow from there to include some aspects of Hungarian Notation… No, not that Hungarian Notation, I'm talking about this Hungarian Notation as clarified by Joel Spolsky.

Finally, Unit Testing. On all of our Java development, we have extensive Unit Testing using jUnit. We don't have 100% coverage, but all of the important fundamental classes that make or break the functionality are covered. Reaching towards 100% would not be worth the time and effort at this point. Unfortunately, our PHP development does not have the same safeguards in place. As all developers know, the difficulties in testing a system are directly related to the number of interactions that happen in the system. While this won't elimnate errors, it will hopefully make them that much more rare.

If your software development organization doesn't have processes like this – or better! – in place, why not?

You are simply risking your efforts, your stress level, and your organization.

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub