ADT Interview: First Practices
(Thu Jan 27, 2005) [/CodeCraft] #
A while back, Mike Gunderloy of Application Development Trends interviewed me for his Five Questions column, which was distributed in a newsletter. With Mike's permission, I thought it would be fun to post the interview one question at a time over several weeks. Think about how you'd answer each question differently. Here's the second one:
Q: If you go into a completely disorganized development shop, which practices do you try to get them started with first?
A: Since developing software is such a high-touch human activity, I suspect the disorganization would stem from a break-down in communication. So I'd start by concentrating on practices that foster better communication.
First, I've had good success helping teams deliver smaller sets of features early and often. The act of delivering working software, of any scale, is a powerful communication technique. For starters, we have to know what it is we're trying to deliver and whether what was delivered is what was expected. That means we need tests to help us check that we built the software right and built the right software. Thus, the more often we deliver something, the better chance we have to converge toward being organized as a team.
Each release also offers multiple points along the way to communicate what's going on. For example, building and testing the software continuously throughout the day is an inexpensive form of communication that advertises the health of the system and helps avert integration problems downstream. Yet, far too many projects don't practice continuous integration.
Small releases also communicate how efficient we are as a team. If after a few weeks we aren't able to deliver a proportional number of features, then we get an opportunity to assess what's slowing us down. Optimizing may involve breaking high-level requirements into smaller tasks, automating time-intensive chores, or finding ways to eliminate waste in the process.
So I'd start with small releases supported by unit and acceptance testing, and set up a continuous integration process to throw up red flags when things go awry. I'd also look for ways to automate repetitive project procedures to conserve time and reduce errors.
Have you tried these practices on your project and if so, how have they helped you keep organized? What other development practices have you found beneficial? How were you able to sell those practices to your manager and others on your team? I'd enjoy hearing your responses on your blog or via email.
