The technical session agenda for the Developer Summit has been posted, and as promised, it’s targeted at the experienced developer. SOAs, Web Services, Performance and Security all have their own sessions. Awesome!

While the whole list of sessions look really good (this will be a busy 2 days!), two that I’m definitely going to check out are:

Developing Cross-Product Solutions and Smart Client Apps with the Mobile ADF

I attended a talk at the 2005 UC on cross product development, and it was really good. Since then I’ve actually done a little of it, and it’s not exactly as easy as you’d think – especially for real-world type tasks. I’ll try to have a some good questions lined up for this

On the Mobile ADF – I saw what I think was the precursor to this at the 2004 UC, and it was very very impressive. I think this is going to be an emerging area, and this ADF will greatly streamline dealing with geospatial smart client apps.

Thanks to all the folks at ESRI for listening to the community and making this conference a reality. See you all in Palm Springs!

Wow! With the length of the thread over at James Fee’s Spatially Adjusted blog, apparently developer support issues have really hit a nerve. I added my comments to the end of that long list, but thought I’d drop them here as well.

My thoughts:

ArcObjects
First off, I’m glad I have a system like ArcObjects to work with. Sure it’s got it’s issues, but really, it’s got a whole lot more functionality in there than anything else out there. Not to say that the open source gang is not catching up in terms of functional GIS, but there are not even close to a unified COM/.NET/Java API like ArcObjects. And some support issues are not going to make me think twice about choosing another platform. That said, we are consultants, so if the end users change, we will follow.

ERSI Developer Network
As far as EDN goes, it’s a godsend for consulting groups like ours. We typically have 2-3 medium size projects and one big kahuna project in the office. To support this sort of development, we need to have 3 or 4 SDE’s, running with different platforms and versions, multiple ArcIMS’s and multiple ArcGIS Servers. For the price, it’s the best deal for us. The only thing I’d like added to it would be developer versions of Desktop – it’s not like we do any production “gis” work, but it would be nice to not have to pay for full seats when they are just used by our clients to test the apps via Citrix prior to deployment.

ESRI Developer Support
My only real beef with ESRI support is that without going to DSG, the only “developer support” is for VBA. And the last time I looked into it DGS was a little spendy for what usually results in “Yes, you have found bug CQ394849″. What would be really helpful would be to able to search the known bugs list from your EDN account. I realize that no company wants to air their dirty laundry (or dirty code in this case), but it would be one way to placate a lot of developers. This may also cut down on the support load, as many times people can find the known issue, add their 2 cents to it, and never interact with the support staff – leaving them able to deal with solvable problems.

After my post about what I considered to be a lack-luster start to the Denver Developer User Group (apparently things got better at the end of the meeting), Jeremiah Lindemann of ESRI Denver (who led the presentation) emailed me to assure me that the developer summit will be aimed at the professional developer.

You also noted concern about the Developer Summit. I would like to make it very clear that this summit will be extremely developer orientated. The presentations will go into much depth with the topics you are looking for. There may be one or two presentations on creating a custom component, but the majority of conference will dig far deeper into true GIS Development (Engine/Server/Web Services/etc). An official agenda should be posted by ESRI soon.

I’d like to thank Jeremiah for responding, and to say that I think that the idea of a developer group is great, I’d like to actively participate. I commend ESRI Denver for taking the initiative in this area (first regional office to start a developer user group); I know that starting up something like this is not easy, and there are bound to be hiccups along the way. Hopefully we can work together to create a strong & vibrant ESRI developer community along the Front Range.

It seems that some people have already located it, but I’ll make this the “formal” announcement of the ArcDeveloper blog. This will be a group blog (more authors = more posts!), dedicated to Arc Developement topics. I think it’s worth noting that although we all work together, this blog is not affiliated with our employer in any way – so while we have “added vitamin C”, it will be “marketing free”.

We’ll be posting introductions, and some “real” content shortly. As for this blog, I’ll keep posting on general .NET, GIS solution architecture, and other less developer centric topics.

See you over on ArcDeveloper!

A friend sent me interesting article on the future of GIS & Spatial Information Managment (SIM) over on GeoCommunity. The article presents the results of an IDC study on the industry, and their 5-year forcast.

Interesting quote #1:

“From enterprise areas like master data management to Google Maps, SIM technology is becoming pervasive,” said David Sonnen, IDC’s consultant for spatial information management.

It’s the pervasive that I find interesting, or rather this is what I’ve been thinking & saying for a while now (see this presentation I gave at CSU on the same idea). The integration with business processes will be tight, and ad-hoc analysis will be less common (i.e. less analysts). And who is going to build & maintain these systems? Developers.

Quote #2

SIM’s migration from a specialty technology to a broad enterprise resource poses both threats and opportunities for geospatial, IT infrastructure, Internet, and business analytics vendors.

So, assuming that IDC has done their homework, there is or will soon be a large community of software developers, engineers, architects and all the other sub-species of software professionals jumping into the geospatial pool. Will the community be able to accomodate them? Will ESRI be able to effectively reach out to this group? Or will Oracle / Microsoft / Google / Open Source be able to better address the needs of this emerging community, and bypass the GIS power houses?

Additionally, the structure and discipline of mainstream software engineering will soon be shaking up existing GIS shops. Having a development process will become more important, as will automated unit testing, agile processes and project managment processes. Some groups will evolve and thrive, while others will not. I also think it’s a sign of a maturing industry which has worked really hard to bring their technology to a place where it can be intergrated with the main stream.

Thoughts?

After posting my description of the ESRI Developer Group meeting, I got to thinking about the term “Developer” or “GIS Developer”, and what that entails. At the meeting, which was specifically called a “Developer User Group”, many if not most people said they were using VBA. And they came to the “developer” user group.

While this does not fit my definition of a “developer”, does it fit yours?

Personally, I think a “developer” is someone who writes software for a living. They study how to write code that’s robust, stable, maintainable, re-usable and efficient. They are worried about usability. They have a development process. They are professionals. It’s what I do, and what my co-workers do. And what a lot of other people do. And as GIS becomes more widespread and integrated into the enterprise, more people from the main stream “developer” community will be tacking the “GIS” on the front.

I’m interested in hearing what other developers think it means. Are you a GIS developer if you code VBA tools? If you whip up some Python scripts? How about a model? Or is there a step up when you hit COM? Or is there some other threshhold?
If you are presenting to “GIS Developers” where should the bar be set in terms of assumed knowledge?

I was excited when I heard about the “Denver ESRI Developers User Group Meeting” down at the ESRI Denver offices. So, today, a colleague and I drove 50 miles down there to attend. Since ESRI seems to be trying to beef up their outreach to the “Developer” community (release of ESRI Developer Network, the Developer Summit etc), I had high hopes for this event.

After taking our seats, and a couple of introductions, the presenters put up the Agenda slide (paraphrased as I did not take detailed notes)

Section 1: Developer Resources
- online help
- support.esri.com
- EDN site
Section 2: Building a Tool
- develop a customization for ArcMap in a COM language

We packed up and left after about 5 minutes. It just was not worth our time. In my mind, what they presented today is about as basic as you can get as a “developer” working with ESRI tools. This is stuff you should cover in the first hour or two of doing development with ArcObjects and ArcMap. If this was a “Intro to ArcGIS customization” seminar, this would be fine, but it’s a “Developer User Group” – we expected more. While I knew that they were not going to touch on automated generation of Geodatabase schemas via XML or other esoteric topics, I had hoped that they would at least show off what can be done if you dig a little deeper – class extensions & object inspectors, ArcEngine applications, ArcGIS Server web services etc. Nope. Basic ArcMap.

Before I go any further, I think that the content of the meeting was perfect for most of the audience. When asked who was currently using VBA to customize ArcMap, the majority put up their hands, so an intro to COM customization is not too far off for them.

However, if this is an indication of ESRI’s understanding of the “developer” community expectations, it raises some serious concerns for me. Particularly for the Developer Summit. At this point, I’m putting my plans to attend on hold until some sort of agenda is posted so we know what we’re getting with this. We can’t affort to take 4 developers out of the office, fly them to Palm Springs, put them up, only to have the summit be focused on the intro level VBA/VB6 COM. And I’d expect that no other development shops can either. We are professional software developers, and I’d expect this summit to be aimed at, or have a track for experienced developers. If not, there is no way we can attend.

Suggestions for Denver Developer User Group
I suggest that the agenda for meetings be posted online, with a suggested experience level for the topics. This will help people decide if it’s worth their time to attend. A suggestion for dealing with groups with a variety of experience levels: have two sections – a fundamentals section which deals with the basics, and an advanced topic which covers things the experienced users would be interested in. This works very well at the Northern Colorado .NET users group.