This is an argument I’ve had ever since using the ESRI products almost 3 years ago.
ESRI by far is the leader in GIS software. They literally helped to make the industry what it is today.
Unfortunately a lot of the code base still is back in the stone-age (technically speaking).
The ESRI products are your typical “kitchen sink” set of applications. They do anything and everything for everyone. The software we use at our school district is the exact same software used by small business, big business, emergency services, utility services and military. The only differentiation is our data and plug-ins.
That’s nice in one sense. I really like having the power of the “big guys” at my finger tips when I want to use it. However, that’s a problem for customer service and developer support. ESRI makes money by developing the new hot features requested by their customers. When Google Maps came on the scene ESRI had to play catch-up really quick to offer an AJAX ready online product. They still haven’t met the mark but they’re trying.
Anyway, the problem is that no one (AFAIK) is maintaining the old code base. This means that the old bugs and usability issues are going untouched. Unless there is a bug or UI problem that is really significant it is put on the “do later” pile.
This is most evident in performance. We are getting ready to install ArcGIS 9.3 on a new set of servers when it is released in the next month or so. So at the last User Conference in San Diego I asked some of the ESRI techs what our server specs should be. They replied “lots and lots of RAM and a high-end CPU”. Notice that CPU was singular. The ESRI code base has been untouched other than bug fixes for years. Even when they moved to higher precision data storage in 9.2 they didn’t go back and update any of the original foundation code. The tech confirmed that ArcGIS products take no advantage of multiple cores or multiple CPUs at all. Ugh!
There is some performance gains if you use a SQL backend for your data or through your web server since these do have multiprocessor support. But as for actual GIS processing, no such luck.
This last comment is helping to fuel our interest in SQL 2008. If you know anything about me, then you probably know I’ve been playing with the new spatial features of SQL 2008 for several months now. ESRI is going to support SQL 2008 when it launches. Hopefully this means that ESRI will be pushing a lot of the processing work back onto the native SQL platform rather than on my desktop.
We’ll see and I’ll keep you updated as we progress.
If you’re going to the ESRI User Conference this year drop me an email and we can meet up.