Dances with Vacuums As the pace of software development continues to accelerate, the way in which we approach it must change to keep up as well.What made sense before isn't as practical now. This past Christmas, my wife Joy asked me for a Roomba [1]. For those of you that don't know, Roomba is a miniature robotic vacuum cleaner that looks like a motorized saucer. I was skeptical about the viability of the product (visions of the Jetsons floating in my head), but I figured it was worth a try. After all, the founders of iRobot (manufacturer of the Roomba) graduated from MIT. Also, for once, I wasn't the one asking for the cool new gadget. We had to wait until the day after Christmas to put the Roomba to the test, because the battery takes 16 hours to charge (humbug). I set the Roomba in the middle of our master bedroom and turned it on. The Roomba began running in circles, then crisscrossed the room, in what appeared to be a random fashion. The longer I watched, however, the more I realized that the Roomba was attacking the problem of vacuuming our bedroom in an extremely systematic fashion. I had expected Roomba to vacuum the room the same way that you and I vacuum a room or mow the lawn. However, you and I have the benefit of sight to help us map out the problem domain. The Roomba had to feel its way around the room and establish those boundaries through logic. Once it established those boundaries, the Roomba was able to make quick work of vacuuming the room, and made surprisingly few duplicate trips over the same patch of carpet. My experience watching Roomba reminded me of the way that software development strategies have changed over the years. I remember a time when developers had a complete specification of a program before coding began. You could start at the data tier and sweep through the business logic tier and user interface tier like software development textbooks tell you to. Most software development projects today are not afforded the luxury of complete specifications. Instead, you get a little information to start and the project's owner expects you to feel out the scope and boundaries of the rest of the system. Some of the highest paid consultants are the ones who are able to efficiently accomplish this task, since once you know the boundaries of the system, filling in the gaps becomes much easier. I started working on an ASP.NET application for a new client the other day. Instead of fighting my way through the traditional software development process, I decided to borrow a tip from my Roomba. I began by circling the nucleus of the system (base application tables), then I shot spokes out to the outer edges of the functionality (demo quality versions of the major screens). I didn't worry about filling in all of the nooks and crannies of the application. I tried to feel out how the size of the system and how the major parts should interact. As my client and I progressed through this exercise, we discovered several deficiencies in our original design concept that we fixed long before we would have discovered them had we gone the traditional application development route. We fixed an amazing number of holes in our design by simulating the user interface experience very early in key parts of the system. Following the Roomba's example, once you build the spokes of your application, you can efficiently fill in the gaps between them to complete the system. Lucky developers have all of the specifications up front. For the rest of us, I suggest this logical approach to tackle the problem in a more effective manner. And just in case you're curious, our Roomba is working out great. It picks up a surprising amount of dirt for its diminutive size. The Roomba has permanently banned dog hair tumbleweed from my home. |