Whenever I hear about a government agency indefinitely postponing their upgrade to IE7, I cringe. We web developers plan on supporting IE6 for at least the foreseeable future, but any setback that delays the natural browser upgrade progress always stings a little. Yes, under the hood IE6 can do most of the stuff that IE7 can, but it does it badly and incompletely.

I listened to Chris Wilson’s talk (he’s IE’s program manager) at the Ajax Experience conference in Boston and he brought up a really good point. IE6 was a great browser when it was released in 2001. Since then the web has changed dramatically. Things are being done with DOM and JavaScript now that just weren’t on our radars six years ago.

Because of that, IE6 is seriously crippled for modern web apps. Aside from its incomplete support for CSS, IE6’s main problem is the execution time and garbage collection in its JavaScript engine. Recent tests show just how dismal the performance is.

I guess this will just be another challenge that we’ll have to work around, but it sure would be nice to hear that larger companies and government organizations are actively planning a browser upgrade.

I think I can say this in all sincerity and without hyperbole: Microsoft Virtual PC 2007 has changed my life. Maybe I’m a little late jumping on the virtualization bandwagon, but now that I have, I’m grinning with Kool-Aid stained lips. Sure, I’ve known that the technology has been out there for a while, but for some reason I just didn’t realize how cool it would be. For me it is kind of like TiVo in the fact that it sounds really neat before you check it out, but once you’ve used it you just can’t possibly live without it.

Before I get into my thoughts and share a few tips I’ve picked up over the past few weeks, I’ll give a quick overview of the technology for those who aren’t up to speed. The idea behind virtualization is that you can use your existing computer to work as two or more computers at the same time. It’s a lot like remote desktop, but instead of viewing another computer in a window, you’re viewing a virtual computer in a window. This virtual machine has a separate operating system and installed software, but can share devices like DVD ROM drives and internet connections with the host operating system.

As you can probably guess, virtualization lends itself particularly well to software testing, where it’s often important to have access to different operating systems and browsers. With a few clicks of a mouse you can load a virtual Windows XP desktop, test your web based software on IE6, and then go right back to your Vista/IE7 desktop. If you screw up the virtual operating system you can just replace it with a backed up copy.

So, now that I have you convinced that you need virtualization, I’ll walk you through the relatively simple process of getting everything set up and configured. First of all, dig around in your bios and see if there is a configuration option for turning on virtual machine optimizations. I have a relatively new Dell laptop, and for some reason the Intel virtualization optimizations were turned off by default.

Then download and install a copy of Virtual PC from Microsoft’s website. Sure, there’s other (and arguably better) virtualization software out there, but this is free!

So, once the software is installed create a new virtual machine. During this process you’ll be asked to define a new virtual hard disk. This is the single file that is used to store all of the virtual files for the virtual machine. Be careful with the size you choose for the disk; it’s a little confusing and I messed up the first time through. The number you choose will allow the virtual disk to grow to that size. It will not take up the space unless you actually use that much inside the virtual machine. Unfortunately, you can’t increase this later, so be careful to not choose a value that is too low. If you have extra disk space, I’d recommend going with 8 gigabytes. I’d also recomend bumping the memory up to at least 256MB or 512MB if you have a lot of memory.

Now you need to install the operating system. Put the windows install CD in the drive and fire up your virtual machine. It’s kind of strange seeing the familiar windows install screens from a desktop window, and this was my first “oh, cool” moment. Another thing I tripped over during the install was that my mouse would become stuck in the virtual machine window. To send control back to the host desktop, just hit the right Alt button.

The next step is to install the virtual machine additions inside your newly installed virtual operating system. These can be accessed from the “Action” menu and allow you to drag and drop files from the host desktop, fixes the mouse locking annoyance, and allows you to share files. This would also be a good time to download the latest OS updates from windows update and install any other software you’re going to be using.

Now that you have your virtual machine image just the way you want it, we’ll back it up. The first step is to run a disk defragmentation inside of the virtual machine. Then run the precompactor utility inside of the virtual machine. You can access this by going to the CD menu, choosing Capture ISO Image, and browsing to C:\Program Files\Microsoft Virtual PC\Virtual Machine Additions\Virtual Disk Precompactor.iso. Finally, perform the actual Virtual Disk Compression on the host machine via the virtual disk wizard (accessible under File in the console). You now have a .vhd file that is ready for backup. That way, if you screw up your virtual machine you can just replace one file and you’re back on your feet.

Please let me know in the comments if my notes were helpful or if I should change anything.

There was an interesting article in the March 12, 2007 issue of Time magazine, The Oracle of Organization. It was interesting because it hits directly on an approach to “performance management” that isn’t often acknowledged or addressed in the methodologies that most performance management software packages are designed to address. It talks about the main task of each individuals daily corporate existence: Getting Things Done. In fact that is the title of the articles subject, David Allen’s, book “Getting Things Done”.

I liked the article because it ties into why Spider is in the business that we are in. On our website, it says “Spider Strategies is a software company” and “Everyone needs to know exactly how they’re performing and what areas need immediate attention. Spider Strategies is the first software company to address all of these needs with an easy to use, web-based software product.” I like the way that sounds, but it doesn’t really say why we are in a business to provide an “easy to use, web-based software product”. The reason is so that people can Get Things Done!

The vast majority of “performance management” software programs in the 90s and early 21st Century also came with daunting training programs. It wasn’t unusual for training to be 40% of the implementation costs of such programs. Worse yet, it wasn’t unusual for companies to spend more time figuring out WHAT they were trying to improve, than getting any improvement done.

We set out to write software that required minimal training because it worked like a) everyone’s browser and b) used the mouse like everyone’s desktop software. Our first attempt, a product called “Scoreboard”, was good but users had to learn not to use the browser back button and, like virtually all static html products, the right click button didn’t work. In other words, we were close but no golden ring.

Our latest product, The Corporate Management Suite, a direct upgrade from Scoreboard, nails the basic goal. The back button and other browser buttons work AND menus are accessed by right click just like desktop software. But does it help “Get Things Done”?

Ultimately, that question is going to be answered by our user community but the feedback has been good. The software doesn’t require the use of “scorecards” if all you need is a simple way for groups and teams to “make decisions about what needs to get done, and then fashion a plan for doing it”. On the other hand, the software does allow you to link to metrics that can be used to determine if you had an impact with what you got done.

The article also says “More than 60 software tools have been built specifically to supplement Allen’s system.” That is not a good thing. Just look at the number of software tools that have been built specifically for implementing “The Balanced Scorecard”. We also believe that when software is build “specifically to supplement” any single idea or methodology, it can get in the way of Getting Things Done because it may require people to get things done in a particular way.

That is why we have been so careful to make our software configurable so that the software can work the way the users normally work to get things done than making the users work the way the software needs them to. Today, our software is implemented for Balanced Scorecards, Management by Strategic Initiative, Process Management by Action Register, Management by Assessment, as well as classical KPI targeting. In other words, the software is configured so that people using those methodologies can more easily get things done the way those methodologies teach.

Finally, when we think about getting things done, we have to think about the time it takes to use tools. I did my first basement build out, framing up the walls with a hammer and nails and the job took a week. The last one I did, I rented a framing nailer and the job took a day.

Software tools need to have evolved and produce that same kind of efficiency. In our military work, we often hear a specification called “The Two Click Rule”: The user needs to be able to get from seeing a red flag condition to the data that explains the reason in no more than two clicks.

When you can get to the reason for the problem in two clicks and then create a corrective action with the third click, that is Getting Things Done. And that is why Spider got into the business that we are in.

My transition from Struts to Spring MVC

I came to Spider Strategies having only known Struts 1.2.x, and I was excited at the prospect of learning a new web framework, namely Spring MVC.

During my job interviews prior to being hired at Spider Strategies, I began to feel like a Struts apologist. Struts has, in some circles, been getting a bad rap. First released in June 2001, I admit its been showing its age. We, as an industry, have learned a lot about developing web applications since Struts’s inception, and no doubt any framework will begin to creak as technology continues its march. That said, I think Struts has held up reasonably well. The ability to integrate Struts and Spring is a testament to both of these frameworks’ extensibility. But, there are shortcomings in Struts that I was eager to leave behind.

These are my initial reactions. Keep in mind that I’m still very much a Spring MVC novice (though not Spring itself). Any mis-characterizations of Spring MVC are wholly due to my ignorance.

My transition so far is pretty easy. The difference between the two frameworks has not overwhelmed me. Both take the same action-oriented approach to web applications, a commonality for which I was most grateful. I have a feeling were I comparing Struts to a page-centric, JSF framework like Shale I would not be able to say the same.

That isn’t to say there aren’t many differences, but learning Spring MVC after knowing Struts was like learning to run with new footwear, as opposed to learning to run on my hands. Spring MVC allows more hooks into the request lifecycle, so I’m no longer limited to simply overriding an Action’s execute method. For example, I can override what is executed right before parameter binding occurs. I can also override “onBindAfterValidation” and perform a routine without messing with the “onSubmit” method. There are several such hooks, which is a refreshing change for me. Of course, having so many can lead to some confusion. I spent some time banging my head against the wall simply because I forgot the order in which these methods occur (thankfully Matt helped me out there — I do hope we’ll share a chuckle over that in the future ). But, Spring has always impressed me with the quality of its documentation, and its MVC component is no exception.

Any Struts veteran has been warned of the dangers of Action-chaining in Struts — that is advice well heeded. That such a pattern can so easily emerge is a deficiency of Struts. It’s a common design to have a “ViewUserAction”, and an “EditUserAction”, for example. If validation failed on the latter action, naturally you’d want to invoke the former action, and down the dark road of chaining. I can’t tell you how many times I’ve seen this, despite the problems it would cause. It also bothered semantically — what “action” was really occurring in “ViewUserAction”? Only after years with Struts I found somewhat satisfactory mechanisms that prevented chaining, namely ControllerSupport and TilesAction. Probably its my familiarity with these classes that allowed me to understand Spring’s controllers as well as I have. Underlying all the Spring request-handling classes seems to be this notion of being a request controller — in other words, an incoming request wasn’t necessarily something you wanted to take Action on. Rather, your job is to facilitate the request hand-off to the view. I dig that.

I’m still getting used to exposing my domain objects to the web tier now that those pesky ActionForms are gone. I’ve spent plenty of time creating fancy “transform(ActionForm)” methods in the past. I did find myself missing the ability to define an DynaActionForm in my XML when I needed a quick object to encapsulate request parameters. While you no longer need to derive form objects from a single class, you do need an object of some sort (when you need a form object at all, of course. Spring doesn’t assume that you need one for every request, unlike Struts). Being able to define validation via XML in Struts’ validation framework is something I miss (though its XML syntax was never something over which I had full mastery).

All in all, so far I’m quite comfortable in this new framework. I think Struts offered a great way to simplify MVC implementation, but didn’t offer you a lot of room to grow once you mastered the execute() method. Spring MVC, on the other hand, offers many more possibilities, and I look forward to exploring.

On Friday I blogged about the disconnect between Theory and Reality in software development. This disconnect is a perfect example of development debt, a topic that Scott blogged about in January. As we continue building our software, we keep building up more and more development debt. Lately I’ve been wondering: when is it going to be time for us to start paying down our debt?

The best thing I can think of is that t here are 2 cases where it’s appropriate to start working on development debt:
1) When there aren’t any urgent new feature requests or bug reports that need to be addressed
2) When a bit of development debt starts to rear its head and manifest itself as one or more bugs

Believe it or not, #1 does happen. There are lulls every now and then, usually after a major release, when there is some time to work on development debt. For example, when we first released CMS 1.0 we had to take some shortcuts to get dojo working properly. As soon as we got CMS 1.0 out the door we revisited those shortcuts and worked out robust solutions, which were incorporated into CMS 1.1.

An example of #2 is a bit of trouble we ran into recently with exports of data to Microsoft Office. There were a number of bugs that came up. For example, exports didn’t work over HTTPS and exports had weird names like “exportWord.doc” instead of “Scorecard Structure Report.doc”. The root cause of these problems was that we weren’t setting HTTP response headers quite right and the code that was responsible for setting these headers had been patched so many times it was now of poor quality.

So, we took a step back and redesigned this functionality. In the process of doing this, we ended up fixing a lot of things that had been broken for a while but weren’t super-high priority. For example, in CMS 1.2 if you tried to right-click on a performance chart and choose Save As, Internet Explorer would try to save it as a BMP file instead of a PNG (BMPs are not compressed, so they are many times the size as PNGs). This is fixed in CMS 1.3.

We have a lot of new features we are working on in CMS 1.4 and beyond right now, and I expect this push will lead to the accumulation of more development debt. In a few months once those features are done, we’ll take the time to start repaying our loans.

Today we ran across an interesting problem in our software. It turned out we had accidentally hard-coded a bit of text in English instead of properly setting it up to be displayed in any language (this is called internationalization in geek-speak).

When we went in to fix this, we discovered the hard coding was done in our data access layer. According to theory, the data access layer has nothing do with internationalization, so we should move the internationalization logic to a different part of the application. In an attempt to conform to proper theory, it meant changing the code in our data access layer. This in turn required several changes to the service layer. The changes to the service layer in turn required even more changes to the user interface layer. As you can see, this disconnect between theory and reality quickly ballooned to the point where a very simple conceptual change would require many changes to the code.

Instead of ripping our software apart to conform to theory, we let reality take over on this one. The reality is our customers want working feature-rich software yesterday. They don’t want theoretically perfect software 10 years from now. So, we just added the internationalization logic directly to the data access layer so that we could cut the latest build of CMS 1.3, which expands CMS’ browser support to IE7 and Safari. We hope to make a general release of this software soon.