I mentioned in my previous post, “The Real World”:

I prefer a short development life-cycle, keeping the requirements for each cycle short and to the point. The smaller the feature set, the shorter every sub-cycle is (design, testing, etc).

37signals recently discussed a great example of this concept with their “Public Contact Cards”. They saw a need, and delivered a solution to it within 48 hours. In order to do it, they kept a very tight focus on the goal of that feature. They solved the problem in the simplest and most direct way possible. They mention several features they could have added and didn’t. Some of them certainly sound like great additions as well, and you may one day see them. But, by keeping the focus on the problem at hand, they can act much quicker to market and consumer needs, keeping their customer base happy, and reducing the risk of implementing new enhancements. They also get a chance to see how their consumers react to the direction of the solution before they have gone to far down the road.

Read more about the Public Contact Cards they added to their new Highrise application.

Technology changes so fast in our society, that our methodologies, procedures, and comfort zones often lags behind. I’ve discussed the lag in acceptance for Telecommuting in my article, Telecommuting: Old-thinking vs New-thinking as one example of societal trends not keeping up with technology.

Another, is in our form of communication. In the past, we communicated almost exclusively with telephones and in person discussions. Now, we have email, chat rooms, and IM. We can access fellow team members at our every whim, even when they are working remotely. But this luxury of communication has it’s drawbacks. We all struggle with distractions, and these forms of instant communication create even more than we would already have. Focusing on a single issue at a time is generally the best method of completing a task, but being bombarded constantly with requests for help on other issues from teammates, requests for status updates on tasks by project management, and spontaneous team brain storming and problem solving meetings all serve to derail us from our train of thought and prevent us from completing the task at hand.

There must times when team members are allowed to focus on their current task, without risk of interruption in thought process. When developers are problem solving, it takes some time for the brain to get into the problem, thoroughly digest it, and get the creative juices flowing to find a solution. But how any times have you been involved in this process, only to be called into a meeting, get involved in an email thread, or be bombarded suddenly with IMs?

Read the rest of this entry >>

Welcome to my new web site. If you have come here through my old web site address, blog.hirebrianburridge.com, please change your bookmarks and links. Hirebrianburridge.com still exists for my online portfolio and resume, but I have moved the “blog” portion to this new site. I have also completely redesigned the site, and plan to add a few more functionality/design enhancements (particularly in the comments section) soon, as well as a lot more content.