Ideal Software Development

I'm the type of person who constantly looks for ways to improve. No matter how well things go, I'm always striving to "plus" an experience - smooth out the rougher edges to make the next time even better. Sometimes the need to do this drives me a little nuts. It drives my wife really nuts!

When things don't go well, this task can be a little overwhelming (and depressing). There are so many areas for improvement, it's hard to know where to begin.

I've spent the last year or so, reexamining my software development experience - looking for trends in the tools and ideas that helped the teams I was on to be highly productive (and conversely where the lack of some practices led to a lack of productivity and frustration). Combined with many of the things I've read by Spolsky, Fowler, and the Poppendiecks. I've created a list of criteria I'd consider essential in an ideal software development environment.

• Talk to the target users of your systems to determine the requirements of the system you are building. Watch them work and try to identify areas to automate - focus on the mundane or frustrating tasks they perform on a daily basis. In a B2B environment, understand the business purpose behind the transactions and the manual interactions they replace. If you can't find or don't have access to your target users, create an idealized version of the people you hope to help and share that vision with your team.
  

In either case, learn as much about the business and the people you want to help as possible.

Document what you learn and prioritize needs (I prefer a wiki as a low friction method to do this).

• Create a schedule based on the requirements gathered while learning about the business. My initial schedule typically looks like a list of the customer needs I've identified sorted by priority.
  

Try and break these tasks down into subtasks that can be completed in a week or less. This will allow you to work in 1-2 week iterations and you'll instantly know whether you are ahead or behind schedule.

Update the schedule as iterations are completed. I've had good experiences using something as simple as a wiki to track scheduled tasks.

• Practice "test first" development. This practice has boosted my productivity more so than any other in this list. The benefits are many.
  

First, test first development requires you to think about your requirements in detail - by defining the code scope needed to implement those requirements. The tests document the "real" (implemented) requirements for your system. It gives you a place to start.

Secondly, it's the easiest way to know that you're finished (when all the tests pass... you're done). This prevents overbuilding (adding extra source code that may be viewed as robust, but doesn't actually meet any requirement). This "extra" code makes maintenance more complex and expensive.

Finally, the tests give maintainers of the code some assurance that their future changes are not breaking any existing functionality. Again reducing maintenance costs.

• Create an automated build. What this means is that you can check out and build any version of the system from source control in a single step (this also implies that you're using source control). Nothing is more frustrating than checking out some source code to work on and not being able to compile it. Sometimes it's because there's no "make file". Sometimes dependent libraries are missing (or you can't identify the correct version). Sometimes it's because someone checked in "broken" code. Either way it's annoying and nothing is worse for productivity than having to track these issues down.

• Manage software releases. Create some method to tag releases (don't all source control systems have a way to do this?) and embed this tag somewhere in your delivered source code. This way, when a customer reports a problem (bug) with the software, they can tell you which version of the software they have and you can check out that exact version in an attempt to recreate and fix the problem.

• Use a bug database. Track all known issues with your software. Work bug fixes into your schedule based on their priority in relation to new features. Again, this can be as quick and simple as a wiki page to track issues and linked to the schedule. Remember, criteria to recreate bugs become additional tests.
  

Ironically, I have experience with all of the items on my list but no single team followed all these practices. The most effective teams I've worked on met most of these criteria. The least productive place I worked had no desire to adopt any of these practices (and was a total disaster).

Also of note is that none of this criteria is tied to any specific technology. Java or .Net - SOA or traditional linear development - open or closed source these practices will make your teams more productive.

The bottom line is getting things done, working efficiently, and delivering value to the business - that sounds ideal to me!