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.

Error of Global Proportions

One of my biggest pet peeves about ASP.NET development is when I see that someone has used Visual Studio .NET (and thereby its code-behind model), yet they've also deployed the source-code files to production. Since .NET compiles the source-code for the entire application into a single assembly in the /bin sub-directory, you don't need to deploy the actual source files, yet many lazy developers do just that.

I can think of myriad reasons why creating an ?ber-assembly is a bad design [2], but that is what Microsoft has given us for this release of .NET, so most developers tend to adhere to that standard. Luckily, Microsoft has discovered the deficiencies of such an architecture as well, and will change things for the better with the release of Visual Studio .NET Whidbey.

I make it a policy to only deploy what my applications (ASP.NET or otherwise) require. While that may necessitate a more carefully planned deployment, I think that is a good thing. However, carefully controlled and restricted deployments can lead to some interesting problems if you forget something.

For example, I often use the Application_Start global event to initialize items in Cache that my application will need throughout its lifetime. A couple of weeks ago when I deployed a solution for one of my clients to the staging server, I kept getting a null reference exception when my code tried to use an object that I had placed in Cache in the Application_Start global event.

I spent awhile going through my usual debugging process and discovered that the code to assign the object in Cache was never executing. But why? After another hour of pulling my hair out, I discovered the problem. While I had deployed my ?ber-assembly to the /bin directory with my implementation of the Application_Start global event, I had neglected to deploy the Global.asax file.

In the good old days of classic ASP, I probably wouldn't have made this mistake because the declaration and implementation of global events were in the same place. In ASP.NET, the Global.asax file is just a shell of what it used to be, but it is still vitally important if you want to use global events.

When you open the Global.asax file in Visual Studio .NET, it just shows a blank design surface. Double-click on it, and VS.NET takes you to its code-behind file. If you open the Global.asax file in Notepad, though, you would see that it contains a single declaration, which binds the Global class in your code-behind file to your ASP.NET application:

<%@ Application Codebehind="Global.asax.vb" 
Inherits="MyNamespace.Global" %>

Once I deployed my Global.asax file, the Application_Start global event began firing and my application sprung to life. Sometimes, it's the little things that cause the most problems. My name is Jonathan Goodyear, and I am the angryCoder.

LINKS:

[1] http://www.roombavac.com/buyroomba/defaultB.asp

[2] http://www.angrycoder.com/article.aspx?cid=5&;y=2003&m=4&d=23