20

We are a small team of .NET developers. We have ample GIS experience, and none of us are new to software/database development or system administration. We have technical degrees and many years of industry experience. We have attended Esri Developer Summits.

Esri's technology - primarily ArcGIS Server, ArcSDE, and ArcObjects - plays a small but necessary role in all the software we develop. Despite ESRI's minority status in our technology stack, we spend an inordinate amount of time troubleshooting elusive bugs, crafting workarounds, deciphering its vague error messages, tracking down performance problems, and recycling processes.

Typically our problems stem from genuine bugs, poor exception handling, limiting design/architectural decisions, lack of documentation, instability, or some combination thereof. (I'm speaking of the ESRI stack here.)

From a project manager's perspective, I'm very concerned about team productivity. This costs us a lot of time. We do not have time to learn every idiosyncrasy of the ESRI stack, but we still need to get things done. (Can't live with it, can't live without it.)

What pragmatic suggestions do you have for increasing developer productivity with ESRI in the mix?

I'm not looking for suggestions on alternative technology stacks.

Improve this question
5
  • 2
    Do you mind be asking the reason behind using ESRI products in your software?
    – OptimizePrime
    May 5, 2011 at 15:29
  • Developers respond well if you threaten to taze them for every bug you find. On a more serious note: your following comment is the normal when using ESRI products. <blockquote>We spend a inordinate amount of time troubleshooting elusive bugs, crafting workarounds, deciphering vague error messages, tracking down performance problems, and recycling processes.</blockquote>
    – CaptDragon
    May 5, 2011 at 15:35
  • @capdragon "We spend a inordinate amount of time troubleshooting elusive bugs, crafting workarounds, deciphering vague error messages, tracking down performance problems, and recycling processes" - that applies to pretty much all software development and installations..
    – geographika
    May 5, 2011 at 15:42
  • 1
    @geographika - Key word is "inordinate" - relative to all the other technologies we work with.
    – nw1
    May 5, 2011 at 15:48
  • 1
    I'd require your devs to watch The Last Lecture, with attention toward the "brick walls" concept ... The brick walls are not there to keep us out. The brick walls are there to give us a chance to show how badly we want something. Because the brick walls are there to stop the people who don’t want it badly enough.
    – Kirk Kuykendall
    May 5, 2011 at 23:27

6 Answers 6

Reset to default
10

For performance it seems the best solution is to write C++ proxy code to ArcObjects as mentioned in this article. In the example ESRI give removal of heavy use of the COM interop gives a 6x performance increase.

ESRI also give suggestions/best practices on handling the cryptic COM error messages - and an explanation of HRESULT error codes.

Beyond these much of the configuration issues are Windows related, and so a good knowledge of Windows server management, IIS, Windows services, Windows event logs, registry, registered COM objects etc. all help.

In addition to these articles, there are a number of more generic development approaches that you may find useful.

Software Development Approaches

  • Use web services as much as possible, for both geographic data (WMS,WFS,ArcGIS REST services). This separation makes things easier to debug and maintain.
  • Where possible install systems to clean Windows installations. Create install scripts so you can recreate the entire system from scratch without having to rely on memory and manual processes. Virtual machines are perfect for this.
  • As much as possible keep pure .NET and DLLs with ESRI specific code separate
  • You could start trying to do more "heavy lifting / processing" in the database e.g. directly in SQL Server 2008 with the new Geometry and Geography classes

Communication

  • Post the elusive bugs to GIS SE / StackOverflow, and if you find the solutions post those too, I've found previous answers I've written myself while searching for the same bug I'd completely forgotten about 6 months later..
  • Keep notes, and ideally allow them to be searchable by others on the team. I've tried wikis but the lack of pasting images was enough of a hurdle to stop me doing it regularly. I currently use Microsoft OneNote which is perfect to keep track of errors, URLs, screenshots. It can be shared as well.
  • For more detailed technical approaches, post them to a blog. There seems to be far less sharing of details in the ESRI world, possibly due to fear of others taking commercial advantage, however a decent blog is a good advert for your company's services
Improve this answer
1
  • Was the -1 for the answer, or having the audacity to mention that developing and configuring OSS GIS is not exactly without the same difficulties?!
    – geographika
    May 5, 2011 at 16:08
7

I fear not a lot of good answers are going to come from this question. But it is a good one....performance of ESRI products has been a concern of mine for some time.

My comment above is querying the need for ESRI products or can you migrate to a different technology stack. If you're developing with ESRI products to integrate with ESRI systems to appeal to ESRI users, then you're stuck with an ESRI code base that has been ported or contorted to fit modern development and user platforms.

Some one from ESRI please correct me if I'm wrong Most of ESRI's .NET libraries are wrappers to COM objects, of which there are overheads to access and offer ambiguous at best error reports and handling. Understanding the underlying COM objects and their involvement in your code base will help you better design your code to suit their operation. This one fact help me increase performance in my Python scripts 10 fold. What once took 40 minutes now takes 4 and with a little tweaking is now down to 2.5 mins!

I've heard good things with ArcGIS 10, but don't hold your breath.

If you're using ESRI products to provide a GIS solution within your software, then latch on to one of the many open source projects on offer and build from there. @capdragon offers one such set of applications that will provide you with a great amount of flexibility and scalability with a support team of like minded developers in the cloud to help you along.

Development with ESRI products is a game of mindfield with ambiguity, obscure hacks and inconsistency the major players if you're trying to do something innovative and outside ESRI Standard Operating Procedure.

I want some one to prove me wrong!

Improve this answer
6
  • To answer your question, we are pretty much stuck with it for too many reasons to list.
    – nw1
    May 5, 2011 at 16:04
  • The ArcObjects .NET SDK are almost entirely runtime calliable wrappers for the underlying COM. The Silverlight/WPF SDK is not COM based.
    – James Schek
    May 5, 2011 at 19:36
  • @James - Correct me if I'm wrong, but isn't the Silverlight SDK just a REST API client? And isn't the REST API built on ArcObjects?
    – nw1
    May 5, 2011 at 21:45
  • @OptimizePrime - ArcGIS 10 made huge strides in many areas you mention and what they have announced for 10.1 even way beyond that. They are completely dropping DCOM support in 10.1.
    – wilbev
    May 6, 2011 at 17:20
  • 1
    @welbev Thank you very much for this info. It has taken some time for ESRI to make head way in this are, but it is pleasing to hear they are addressing these concerns.
    – OptimizePrime
    May 6, 2011 at 18:11
7

In my experience working with ESRI, the farther you can get away from ArcObjects, the more likely you are to have success. In practical terms, that means if you can use the newer REST APIs to do what you're doing, you should always access ArcGIS that way.

They seem to have learned something from the total failure that was the Web ADF in Java/.net, and the REST APIs are much simplified and have a comparatively great track record at just working without a lot of fuss. The simplest way to access the REST API is if you're doing work in Javascript/Flex/Silverlight as ESRI provides libraries for those that are pretty good, but it's just a standard REST interface and you can talk to it with almost anything.

There's stuff that you can't do that way, but I can't stress enough how much nicer it is to work with then almost anything else in the ESRI stack. When you have to work with ArcObjects (or the .net wrapped ArcObjects), all you can really do is create extremely good documentation in your code and pray that they don't break stuff in the next patch (which they probably will, knowing them).

Improve this answer
6

Keep your support maintenance up to date. The only thing more frustrating than trying to figure out a code problem is trying to figure it out with no help from the people who wrote the code. And you will receive no help whatsoever from ESRI if you don't have a maintenance agreement with them. (You might get some help from this site or the ESRI forums, but that's a far cry from talking directly to them.)

Stay on top of service packs and patches. You're not guaranteed to have no issues if you do, but you can safely answer, "Yes," when asked by support if you have the latest version/updates installed.

Contribute your workarounds to the community (blogs, questions here, etc.). If enough people did that, I imagine two things would happen: one, more developers would be aware of the issues and would have a fighting chance to stamp them out more quickly and two, problems would get fixed faster by ESRI (nothing like a magnifying glass to get the ants moving, is there?).

Improve this answer
0
4

I'm also a ESRI developer that fights constantly with this product on a daily basis. I do not have a maintenance support, so I don't get much feedback from the developers.

It's really really really frustating when something "Just Doesn't Work" (as opposed to IJW - It Just Works), not matter how hard you try.

What I do try to win the fight:

  • Ask questions (a lot)
  • Read ArcObjects SDK reference (a lot - over and over)
  • Experiment with different setups

The shortest path to a result is asking someone that already had the same problem, so, if someone got into that trouble and found a fix, they will most likely tell you.

The documentation is good, but lacks key element descriptions and important details - so, go back to 1.

Experimentation also works. Create a console program and test away. Unit Testing frameworks can help you do everything inside a IDE, but test different scenarios.

The buggiest or weirdest of ESRI libraries is Geodatabase and can give bizarre results, depending on conditions, so try to master it.

Improve this answer
1

Try using PostGIS > GeoServer > OpenLayers. See how that works for your team.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.