Increasing developer productivity with ArcGIS platform?

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

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!

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).