Spider Strategies Blog

The latest news about our company and software

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.

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

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.

This got me thinking, could we harness the power of wikis to help us generate and improve documentation for our software? Perhaps we could reformat Joe's user guide into a wiki format and then anyone within the company or outside the company can improve the documentation with tips, tricks, etc.