During lunch I ran across an interesting article from CNN Money about Wikipedia and Wikia (a for-profit offshoot).

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.

Apache has a wiki that has some documentation on it, so that can give us an example of how well (or not well) a public documentation wiki works:

• Tomcat wiki
• Log4J wiki (very popular project)
• Apache wiki (contains Log4J, Tomcat and more)

It looks like there’s some information in the wikis, but nothing very interesting. Taking Tomcat as an example, you’ll see that their “real” documentation isn’t on the wiki at all. I think they may have had better luck if they had moved this content to the wiki. Only Tomcat developers can modify the “real” documentation at tomcat.apache.org, whereas Tomcat users (a much larger # of people) could modify the wiki content at wiki.apache.org.

So let’s take this out of the hypothetical and make it concrete: Joe, how difficult would it be to transfer the contents of the user guide into a wiki format? Spider software users: would the wiki format be easier or harder for you to use than the current Word document format? Also, do you think there might be someone in your organization that has particular expertise with Spider software that would like to contribute to something like this?

I am a car nut. I also love technology. Any time these two industries meet up together, I am a happy guy. Although electric vehicles have had a rocky start the last few decades, it seems that a few companies are making leaps and bounds relatively quietly. One of the more notable, Tesla Motors, has recently been making a few headlines. Imagine a car that has Porsche-like performance, Lotus-like appearance, yet only costs about a penny per mile to drive.

It is by no means the cheapest electric vehicle choice out there, but very well may be the most practical to date. The motivating factor behind this is the Tesla’s incredible range. The company claims a 250 mile range before needing a recharge. That takes this from being a limited commuter car to a practical second vehicle. You still can’t reasonably drive it across the country, but there aren’t many people out there with the need to drive more than 250 miles a day. All you have to do is park it in the garage at night, plug it in, and it’s ready again for you in the morning.

Electric vehicles aren’t necessarily better for the environment, but they can be. It all depends on where your electric company derives its energy source from. If they are using hydro, wind based, or other environment friendly means, then the Tesla Roadster effectively becomes a zero emissions vehicle, reduces our dependency on petroleum based fuels, and ultimately makes the world a better place for our children. The roadster is currently sold out for 2007, and orders are already being lined up for 2008. Not everyone will be able to afford one yet, but as they become more popular and mass-production options bring the initial cost down, don’t be surprised if you see one next to you at the stop light. Don’t worry though, when he leaves you in the dust, it will be a much cleaner and quieter experience than you are used to.

I sometimes regard the term “unit test” as unfortunate. It’s certainly important that test cases actually certify your code, but in many ways I’ve come view that as a pleasant side-effect.

For developers unfamiliar with unit testing, the “test” aspect might be a tough sell. After all, they can actually see their code working once they’ve deployed their application. Indeed, prior to being hired at Spider Strategies, I found I had to disabuse potential employers of the notion that my unit testing experience was solely a function of QA.

For me, the less obvious benefits of unit testing are the more profound. Chief among them, it allows you to be more intimate with your code. One of the essays I enjoy in Getting Real is “Code Speaks”. Being metaphor-minded, I savor the conceit of listening to one’s code.

Allow me to stretch it to an absurd degree: if you’re waiting until you’ve deployed your application to listen to your code, it’s akin to having it shout at you from across the street. It’s much better to engage in a conversation with your code when it’s sitting nearby. In any good conversation each party can interrupt, correct, and acknowledge. Unit testing provides just that level of intimacy.

If you’re coding your test and find yourself having to create a dozen mocks and stubs, your code is telling you it is overly coupled. Once I found myself needing to mock the very class I was testing so that I could simulate a method invocation that took place in the tested method. That was my code telling me it was time to extract class. It has become accepted wisdom that tests should inform one’s design, and I’m glad for it. Code that is hard to test is generally accompanied by that foul odor with which we’re all familiar.

Do my test cases actually test? I suppose they do, in the end. But much like my IDE, I regard unit testing as a tool that allows easier software development.

I read an interesting blog the other day: The software business model is dead. May it rest in pieces.. Of course, I’ve been reading similar things for a number of years. However, this one caught my attention because it struck me as not simply about the software business model and also about the “performance management” business model.

According to the Wikipedia, “Corporate performance management (CPM) is a concept introduced by Gartner Research in 2001, which “all of the processes, methodologies, metrics and systems needed to measure and manage the performance of an organization. and that is the way that I used to think about it. I don’t think I’m the Lone Ranger in that respect. If you google “Corporate Performance Management” you’ll see all of the usual suspects competing in the Business Intelligence, Database Management, Data Warehousing world advertising their approach to CPM.

Today, I don’t think of it that way. After almost ten years of working with companies trying to improve performance through better project management, six sigma, quality circles, BSC, process management and more, I’ve come to appreciate that managing performance is, at its core, about people.

That is why this article struck me as succinct and to the point. Go back to the article Ray Lane: Good riddance, software business, and take note of some comments he makes about the software business in general:

• we’ll see fewer…and far more user-generated and user-driven applications.
• collaborative environments, and mobile capabilities are the types of applications a new generation of users expects
• Now, it’s about collaboration. We’ll use the power of individuals for the benefit of the enterprise.

The emphasis is not on the software, it is on what the software is supposed to do! It is supposed to empower people to work smarter, work more efficiently and “benefit the enterprise”. In other words, it is supposed to empower people and the enterprise they live in to positively affect performance.

When I read these posts, I can hear echos of lines from TS Eliot’sThe Journey of the Magi,”

“This: were we lead all that way for
Birth or Death? There was a Birth, certainly,
We had evidence and no doubt. I have seen birth and death,
But had thought they were different; this Birth was
Hard and bitter agony for us, like Death, our death.
We returned to our places, these Kingdoms,
But no longer at ease here, in the old dispensation,
With an alien people clutching their gods.
I should be glad of another death.”

I remember back when I was writing code, before I moved into “management”. It was 1972 and I turned in my code in stacks of long brown boxes with each line on a single punch card. I also remember that day when the Wang guy stopped by the lab with this strange device that saved code on cassette tapes.

Each step along the way in the evolution of software is both a birth and a death, but not just for the software business model….

As a gadget lover, the Consumer Electronics Show (CES) is my annual awards event of choice. Others can have the Oscars, the Grammys, and all of the Pageants combined. For me, it’s all about what new gizmos are coming out that are going to make my life easier, happier, or more productive.

This year was no different. Although life always seems to prevent me from attending, I followed the highlights from the 2007 show in Las Vegas on both CNET and the CES website. As you can see from the list of 2007 Award Winners, these gadgets are all about making life more enjoyable and perhaps even a bit more productive. CES 2007 highlighted everything from a fully voice-activated control system for your car, in the Ford Sync (through a Partnership with Microsoft), to a PDA/Smartphone designed to play TV programs.

Really? TV on a cellphone? Well, this, coupled with Steve Jobs official introduction of the Apple iPhone at Macworld 2007, got me thinking about mobile productivity in the next 2-3 years. Looking back, the last 5 years have brought the onslaught of the Blackberry, Treo, and other PDA/Smartphone generation. These devices have allowed us to get away from our desks (although never away from work), by bringing our email, documents, presentations, and even the web right to our pockets. And now, it seems, TV, videos, music, and more.

So, as the technical world and the business world further collide, will more business be done via hand-held computers? Perhaps the V- Cast and iPhone don’t convince you. But, how about the new OQO Model 2? This is a palm-sized mobile device with the specs of a PC (1.5GHz CPU, 60GB HDD, and 1GB RAM, the model 02 computer supports Microsoft’s next generation operating system, Windows Vista).

Well, since we here at Spider like to be out ahead of the curve, this got us thinking: “How are we going to embrace this new Mobile Generation?” For starters, we modified this very blog page you are reading to make it accessible via mobile-internet. That’s right, your favorite blog is now available anywhere, anytime right from your mobile device.

But, that’s not all. It’s one thing to make your Blog available via mobile internet; In the next several months, Spider will be looking to integrate mobile accessibility into our products. Meaning you would be able to access our Corporate Management Suite via any web-accessible PDA/phone.

We’re just getting started on this, but we are extremely excited about the use of this technology and what it will mean for our customers. In the mean time, if you have any ideas or suggestions on mobile-web applications, we would love to hear them.

There are all kinds of situations in web applications were you need to collect information from the user, and our Corporate Management Suite is no exception. Like many web apps, we used to pop open a new, smaller browser window for this purpose. It certainly got the job done, but there were all kinds of problems.

The most annoying of these were popup blockers. Not only do the new browsers ship with blockers installed and activated by default, but add-in toolbars from Yahoo! and Google closed our new windows as fast as we could open them.

We also had problems with this popup window confusing novice computer users. It completely took them out of the flow of the application and they sometimes became lost if they temporarily switched to another program or accidentally clicked somewhere else.

Finally, and maybe most frustrating to me, the darn thing just looked ugly. It was always the same size, didn’t move with the main browser, and taunted us with its operating system specific minimize and close buttons.

After a fair amount of internal debate we decided ditch the popup window and move to a Dynamic HTML modal dialog. It ended up being a fantastic decision and we haven’t looked back. Gone are the days of having the popup and main windows get out of sync. Our dynamic modal dialog is actually part of the HTML page now, and blocks you from clicking anywhere else while it’s open. It also resizes automatically based on screen real estate and adds scrollbars when needed.

We’ve since incorporated the code into our webpage, so you can go to our products page and click on the automated product tour button on the right to see an example of it in action. The code is an extension of Dojo’s modal dialog and I’d be happy to clean it up and provide it for download if there’s a demand.

It’s not very noticeable yet, but the latest buzz on tech sites is about a new laptop display technology. It’s called LED backlighting, and it looks very promising. A variety of sources have reported smaller versions of the displays being available right now, and predict that larger displays will be commercially available from HP and Apple in the next six months.

LED backlighting is a huge step forward for a variety of reasons. Not only is it considerably brighter than the current generation of displays, but it promises dramatically increased battery life, higher contrast ratios, and thinner form factor. I don’t know about you, but I’m going to hold off on that MacBook Pro upgrade for a few months.

Like many web-based software companies, a significant part of our frontend logic is dependent on JavaScript. This allows us to add all of the neat little animations and dynamic page updates that make web apps fun. It also dramatically increases the size of the JavaScript files that need to be downloaded.

Our approach in the past has been to just cache everything and forget about it. Unlike many public websites that have to operate under the assumption that the user’s cache will be empty, we can depend on a fairly high percentage of populated caches. And, because we have a single page application design, even if they don’t have the JavaScript cached, they only have to download the files once and they’ll be available the entire time the application is being used.

Our problem has actually been that pages are cached too much. We update our software fairly often, and most of the time these changes affect the JavaScript. When someone tries to use the app with outdated files in their cache all kinds of annoying blowups happen. Development was also a pain because we had to constantly keep clearing our browser cache to test new code. It wasn’t until recently, though, that we implemented a solution to these problems.

Step 1: Force Cache Reload After Upgrade
The most serious of caching problems was that people would have to manually clear their browser cache after we upgraded the application. This was solved by dynamically sticking the application version number into the JavaScript file’s querystring. Every time the app was upgraded the version number would change, as would the querystring. And, because the browser sees a new query string variable, it downloads the file from the server. The HTML being generated ended up looking like this:

<script type="text/javascript" src="js/dojo/dojo.js?redownloadToken=1.2.17"></script>

Step 2: Make the Developers’ Lives Easier
Developers are smart folks and can usually figure out when cache needs clearing. Just because they can, however, doesn’t mean they should have to. To remedy this problem we added a “development mode” to the app. When enabled, the redownloadToken above is changed from the application’s version number to a timestamp, effectively forcing a cache-free download on every page refresh. Even better, when development mode is enabled the app automatically uses the uncompressed dojo build for maximum debugability. Here’s the JSTL code we used:

<c:choose>
<c:when test="${development}">
<script type="text/javascript" src="<c:out value='${baseUrl}'/>/js/dojo/dojo.js.uncompressed.js?redownloadToken=<c:out value='${redownloadToken}'/>"></script>
</c:when>
<c:otherwise>
<script type="text/javascript" src="<c:out value='${baseUrl}'/>/js/dojo/dojo.js?redownloadToken=<c:out value='${redownloadToken}'/>"></script>
</c:otherwise>
</c:choose>


In the end we haven’t solved all caching problems, but our customers and developers are sure happier!

Part of what makes software development fun and interesting is working with cutting edge tools that enable developers to build fancier and (more importantly) better mouse traps. One such tool that we’ve come to embrace in working towards improving our application is the Dojo Framework. Full of features that create a rich and visually stunning AJAX application, version 0.4.1 of the Dojo Framework was recently released to the general public.

We here at Spider Strategies were looking forward to this new release to aid us in one particular problem that plagues all web applications, browser compatibility. In particular with Microsoft’s new IE7 being pushed out to clients automatically, we definitely wanted to see how Dojo and our performance management application, CMS, would fare against Microsoft’s latest browser. We also had an interest in see how well things worked when applied to Apple’s latest Safari 2.0.4 browser, for those inclined to work with Apple. As a side note, because we’re all developers, we do most of our development on Firefox (how could a web developer live without firebug?) and therefore are most interested in these other major browser platforms.

All developers know upgrades can be a double edged sword; fortunately nothing major broke and most of the problems we encountered were relatively minor and were due to some changes applied underneath the Dojo hood. This meant most of the changes we made were syntactic in nature. For example the way Dojo expressed coordinates in previous versions syntactically was the following :

[top, left]

In 0.4.1, this was changed to :

{ top: val, left: val }

A minor change for sure, but one that expresses the foundation for most of the problems we encountered. Other types of issues we encountered were due to some refactoring of the Dojo tree widgets, specifically the events associated with opening context menus and the ability to drag and drop tree nodes. In one instance the method of construction used to create our context menus had to change from using Dojo topics to using the dojo.event.connect system. While most problems were encountered were not specific to IE7, we did run into an issue with IE7 not being able to correctly calculate the height of content within a pane. However, this is somewhat a non issue as we plan to incorporate a custom dialog in the future.

Safari, on the other hand, proved to be a whole other beast entirely. Right from the start, there were problems immediately noticeable after logging into our application. In addition to several of the problems found common to other browsers, Safari went the extra distance in providing poor editor support for rich text editing and context menus. Ironically, Safari also provided the worst usable user interface (Apple is known for their sharp UIs) when compared to IE or Firefox. Many of the visual elements such as expandable boxes or cues provided during the dragging and dropping simply did not work, or just looked plain ugly. With the exception of the rich text editor, however, we were able to smooth out most of these issues. The rich text editor proved to be the single biggest challenge in getting Safari to work properly. The problem lies in the editor code of Safari 2.0.4, and while we implemented a workaround for this shortcoming, we hope the next version of Safari will be more kind.

Everyone expects to encounter problems to some degree when it comes to upgrades, but all things considered, the upgrade to Dojo 0.4.1 and IE7 went well with no major issues. More importantly, we now have full browser compatibility with “the big three” browsers, with most of the nuances in developing a cross browser web application transparent to the developer. This perhaps showcases one of the nicest benefits we’ve received after using the Dojo Framework to power our application.

One of my favorite sites when it comes to “performance management” is http://www.12manage.com/index.html. It is a perfect example of the global effort to sort through the confusion around “managing” performance. However, since I’ve been working in business since 1972, my favorite part of the site is:

http://www.12manage.com/methods_rockart_csfs_kpis.html

This short essay reminds us that the core of managing performance is embodied in two concepts that are over 20 or 40 years old: Critical Success Factors (CSFs) and Key Performance Indicators (KPIs). Furthermore, it reminds us that both organizations and an organization’s goals are hierarchical in nature.

This natural hierarchical nature of managing performance is exactly the foundation we used to code The Corporate Management Suite. Furthermore, since organizations and their goals consist of multiple hierarchical relationships linked vertically, horizontally and diagonally across the organization, we created the fundamental ability to link anything in one hierarchy to anything in another hierarchy. This mirrors the way that CARs in Sales Administration may be linked to Engineering Change Orders in production.

The fact is, however, that representing the true hierarchical nature of organizations and performance aims is not an easy programmatic task to accomplish without severe software performance costs.

The method taught and used until early in this decade for the programmatic creation of hierarchies was a method called the “adjacency list” method. In the internet age, the big problem that people saw with the adjacency list hierarchy model was simple: the larger the hierarchy, the slower it was to represent across the web because all of the data from the tip to the root of the structure had to be pulled through the pipe to get to the client browser. The result was often a several minute delay after logging in to a “scorecard” application before you could start working on the data.

Fortunately, when Spider started coding performance management software, a new method for building hierarchies using “nested sets” had started getting a lot of attention in the literature. A good example is http://www.codeproject.com/database/nestedsets.asp which was published in 2003. However, the best known source for the concept is Joe Celko and his book “SQL for Smarties”. In fact, you can find articles in 1996 where Joe talks about the concept, http://www.dbmsmag.com/9603d06.html.

The good news is that Spider incorporated the methodology in the core of our software from day 1. The result is software that deploys in assessment situations like the MNF in Iraq where there are up to 600 “scorecards” with n level structures linked both to documents and actions, yet calling the information for any one pulls no more information across the net, than would be called in a simple 6 level small business hierarchy!

When it comes to speed and performance across the web in the 21st century, it is all about how you represent the hierarchies.