A few months ago, we started development on Geocortex Optimizer 1.3.

In some ways, this release was like many others. We had more features than we had people-hours to develop. We had the normal number of technological challenges and experienced the early project stresses as we moved features from the poorly defined fuzzy pile to the completely understood and fully implemented pile. We also had the usual dose of competition for developer resources as development priorities moved over the three month development cycle.

This release also seemed quite different and it was initially hard for me to identify what the cause was. Normally, two weeks before a final release, the product is really solid and a nice clean release is all but a certainty but two weeks ago, things seemed to be challenged. I was puzzled. We followed the same development methodology we normally do. We performed the same level of testing and had a nice long beta period. Our customers were involved in the development process which is a positive success factor on any software projects but for some reason, things didn't seem to be coming together as they normally did.

I thought about this long and hard and then realized what was different: we released our beta before it was feature complete. You see, we decided to add report configuration to Geocortex Optimizer but when we started working with it, we realized that our users were going to have trouble with it. It didn't flow as well as we would have liked and the consensus was that with a little effort, we could make it much better. At that time, we were close to our beta release so we decided to release it as-is and rework during the beta test period. I now understand why the often recommended yet infrequently followed advice proffered by the software gods is to release a beta when you are feature complete and to only fix bugs during the beta period. While I am sure that our decision to improve configuration was the right one, software project managers should realize that doing so increases risk and adds a substantial amount of pre-release excitement. Iterative development can sure be uncomfortable at times.

Notwithstanding these challenges, Geocortex Optimizer 1.3 will be a good release with some great new features. Here are the most significant additions:

  • Report configuration. I think this feature really turned out well and it will enable our customers to easily view their data in a number of different ways. It is a good tool; sometimes the difference between using something well and not using it at all is good tool support. I think our report configuration provides this in spades.
  • API Support. In addition to Web ADF, Geocortex Optimizer now fully supports ESRI's new JavaScript, Silverlight and Flex APIs. ;
  • Support for ESRI's 9.3.1 optimized map services. Many of our users are taking advantage of ArcGIS Server's optimized map services (MSDs). Geocortex Optimizer 1.2 predated these services and as a result did not support collecting stats for them. It does now.
  • Upgrading. The feedback we received from our users is that they would like to not have to reinstall and reconfigure Optimizer each time they upgrade, no matter how good we made the configuration utility. We listened and it's now possible to directly upgrade from Geocortex Optimizer 1.2 with few issues.
  • Documentation. We collect a lot of data and have a large collection of reportlets that roll-up that data into a useful form (assuming you're clear about how that data informs decision making). We got feedback that people wanted more guidance and insight into what a given report is telling them and what they could/should do with information in a given report. For 1.3, we've endeavoured to create better interpretive documentation describing how best to use the information contained in Geocortex Optimizer reportlets.

Existing Geocortex Optimizer users are able to download version 1.3 from the Geocortex Support Center