On being a GIS Developer, Part 2

Here is this week’s entry on being a GIS Developer. For Part 1 click here.

21. You must be able to think abstractly at one point and with great focus and precision at another point. GIS is by its very nature an abstract proposition. We are always dealing with representation of one form or another. On the other hand, when writing code you must be able to switch to the more logical side of your brain.

22. You should be able to reason and also listen to reason. Pay attention to what people are saying and how they are saying it. Develop your emotional intelligence as well as your rational thinking abilities. Learn to read between the lines. Learn how to spot logical fallacies and effectively respond to them.

23. You should understand that others don't understand GIS like you do. As a developer you understand GIS from a completely different level than most others. When they see a GIS they see a fancy map but you see points, polylines and polygons, vertices, and other complexities.

24. You should be willing to mentor others. Once you’ve gained some experience be willing to help others grow. Not only does this help your team it helps you hone your knowledge and skills because it forces you to really know what you’re talking about.

25. You should understand that your personal gains must sometimes be sacrificed for the goals of the project. Sometimes you’ll have to let your skills lag so that your organization can keep a customer. This is hard one for developers because we’re always trying to stay ahead of the curve.

26. Understand that pride and ego have can be an impediment in this field but are often a great driver behind the motivation of GIS developers and others. Take joy in the benefits you bring to a project. Also, realize that you will work with people that are smarter than you. Don’t feel threatened; learn from them.

27. You should be able to communicate to your superiors how realistic something is or isn’t. You don’t ever want to promise something you can’t deliver. Also, try to help your team not promise something they can’t deliver.

28. You should be fair in your criticism and try not to take something personal when someone else criticizes your work.

29. Always try to improve but also don’t re-invent the wheel just because you can - code reuse, knowing what's already developed, etc.

30. You should be familiar with your organization, its culture, the people and their knowledge, and how you can utilize it in your efforts. Learn the history of what's been done, what was cast aside, who the players are, etc.

31. You should know your customer and/or users. Learn why they do things and what their issues and frustrations are. Gather as much written information as possible but also talk with everyone involved so you can get feel for their views on the project. What do they expect? How do they work? What’s their culture?

32. You should realize that building a new app or new tool isn't always the solution. Sometimes it's just a matter of changing the data or changing the business process.

33. You should always be prepared. Always know the purpose of a meeting and why you're going to be there.

34. You should try to work as closely as possible with the end user. They will be the ones that actually use your software so they should be your focus.

35. You should avoid the politics of the organization if at all possible. There is nothing more corrosive to a successful GIS than politics.

Facelift of ESRI's Resource Centers

ESRI has replaced the interface to the resource center. It looks better and it's easier to get to the developer links.Once you navigate to one of the individual resource centers just click on the For Developers tab to get the good stuff (i.e. code library, samples, etc.). It's a nice improvement. I just can't figure out why it took them so long to figure out that the old design was pretty bad.

Bugs resolved in ArcGIS 9.3.1

ESRI is targeting April/Map for the release of ArcGIS 9.3.1. They have released a list of the fixes. Here's a breakdown of the total number of bugs and enhancements that were resolved in this upcoming new version:

ArcGIS Desktop - 196
ArcGIS Engine - 11
ArcGIS Server - 99
.NET Manager - 7
.NET Web ADF - 37
Java Manager - 4
Java Web ADF - 6
REST API (Java) - 1
Image Server - 26
ArcSDE - 69
ArcIMS - 2

That makes a total of 458 issues that have been resolved. It would be interesting to compare this to previous releases which could tell us if ESRI is improving over time. Also, notice that ArcGIS Desktop has the most enhancements/bugs that have been resolved. This makes sense because it is the primary product that ESRI users use. But, ArcGIS Server is receiving the most new features as evidenced in my post about the amount of the interfaces that were released in 9.3. Surely all of those new interfaces don't have a proportionate number of new bugs.

Dealing with LiDAR data

For anyone that needs to convert LiDAR data here are a set of tools that may be of interest:

libLAS - a c/C++ library for reading and writing ASPRS LAS files.

and to get the data into ArcGIS use the LAS to Multipoint tool in ArcGIS. Another useful tool is from VLS Software and it's called LIDAR Analyst. Lastly, you can also use LP360 from QCoherent.

On being a GIS Developer, Part 1

I thought I’d share some of the things I’ve learned over the years from being a GIS developer. The following is just a list of things I’ve observed, learned or advice I can give from working on a few dozen projects. Some of the items are specific to GIS while others could be applied to the IT professional and then some others could be applied to life in general. Also, I’ve grouped some of these together and some others aren’t grouped because I think they deserved their own position on the list. When I started compiling this list I realized that I could go on and on so I’ve tried to limit it. Furthermore, these are in no particular order. Lastly, if you’ve been around for a while you will find some of this pretty obvious but if you’re new to this profession some of it may not even make any sense. Regardless, I hope it’s a good start and that you find it helpful. This article will be divided up into 3 parts over the next few weeks.

1. GIS Developers tend to always be thinking about some problem they are having, some new piece of technology or just something they’ve learned about or another way to solve a problem. It’s just the nature of the work and you must be someone that enjoys thinking a lot.

2. You should always try to keep learning and learning fast...learn everything you can. Read GIS books, attend conferences, talk to others, etc. All of this knowledge adds up over the years and makes you even more useful and able to apply your skills and knowledge in different ways.

3. You must be creative and have an entrepreneurial approach. Necessity really is the mother of invention. I never had much of an entrepreneurial spirit until I owned a GIS company. There’s nothing more creative inducing than having to put food on the table. Many a programmer would be better at their job if they just acted like it was their own business.

4. You must have a strong work ethic, excellent problem solving skills, be objective, honest, cope with stress, multi-task, and pro-active, team oriented and/or able to work alone, good interpersonal skills, a strong desire to help people, be willing to share what you know, tenacious, dedicated, open minded and so on.

5. Most of the time you will be more of a generalist than an expert in this field because you will constantly need to go from project to project or from one version of the GIS to another.

6. As a GIS developer you must have a solid knowledge of GIS, cartography, software engineering, databases, remote sensing, Web tools, geography, spatial analysis, etc. The list is long and every year it seems to get longer.

7. You should understand related subjects like computer science, mathematics, operations research, etc. I can’t tell you how much I now need to know now in regards to math as opposed to when I first started in GIS. Even knowing something like photography, physics, or forestry can help.

8. You should understand ESRI and the way it thinks about GIS. You must know ESRI's algorithms or at least know what published algorithms they’ve based their software on. On several occasions knowing what algorithms ESRI uses and how they’ve implemented them has saved my butt.

9. You should understand software development like Rational Unified Process, Agile, etc. You must understand which one to use and it’s highly dependent of the business domain. Also, test, test, and test again. There’s nothing worse than having a user tell you your application doesn’t work.

10. You should be able to work with analysts, subject matter experts, editors, managers, end-users, etc. All of these team members will have different perspectives on GIS and all of them are equally valid.

11. You should be aware of standards and able to apply them. They can sometimes be a real limiting factor but you’ll still have to work with them. They are important and make GIS easier for everyone to understand and use.

12. You should either know about the subject matter domain or learn about it. I’ve now worked in several industries (electric utilities, local government, military, banks, etc.) and each one has a different set of regulations, policies, geographic properties and so on that are unique to them. You must be able to adapt your knowledge of GIS to these domains.

13. You should understand hardware, OS, networks, etc. Sometimes the difference between success and failure is knowing how one OS handles files differently than another. Also, in order to build a workable architecture you should understand the pros and cons on the underlying hardware and network.

14. You should have excellent communication skills: written and oral. Also, you should learn the art of persuasion. Develop your public speaking skills.

15. You should be aware of the GIS market and the tools that are available. Sometimes you won’t be able to develop a tool but you must be able to give management an alternative. Also, understand the relationships between different vendors and who will work with whom.

16. You should be willing to take managed risks. Sometimes you’ll be the only one that understands what needs to be done or that a new piece of technology may provide the solution you need. Hopefully, you’ve built enough trust from others to take this risk to develop it. Of course you must temper this with pragmatism and cost and other factors.

17. You should be an evangelist. You must be willing to promote GIS and new tools to others. Often you will be alone in your endeavors but if you don’t overstep you should be able to persuade others of the benefits of some new technology or approach.

18. You should be able to switch different parts of your mind. One minute working on code and the next giving a demo, and in some cases the next doing marketing. It just depends on the organization you work in and your own abilities.

19. You should understand business process modeling, data modeling, object models, etc. You will come across many of these in your career and some of them will be very complicated and if you understand all the symbols and icons it’ll make your job easier. This is how the GIS professionals communicate conceptual details to each other.

20. You should keep up with the latest research and technology trends. You never want to be caught with your pants down. Learn about new technologies and determine their advantages and disadvantages. Try to determine if and why the GIS vendor has or hasn’t implemented something.

Shooting in the dark

As a developer I like to first create a map in ESRI's desktop software first and then re-create it using code (design and build). For example, I may want to add some rasters, TINs, featureclasses, etc. and then exclude the unnecessary features, label the features, render the layers correctly, etc., and then try to reproduce these same conditions in my code. While most of the time this is pretty straight forward, there are many occassions, especially with ArcGlobe or ArcScene, that this is very difficult, if not impossible, without having to contact ESRI and find out how to repeat what's been done at the desktop level. It's like shooting in the dark. On many occassions it's just a matter of knowing what property to set on some interface or what method to execute. While it may be just one thing that's missing the difference between knowing and not knowing can mean success or failure.

What ESRI needs to do is develop a tool for us developers that once you've built your map or scene you then open a tool from the the desktop software and it tells you all of the objects and interfaces that were used to build it. In fact, it would be nice if it completely generated the code for you in the language you need or at a minimum generated the pseudo-code and a list of all the objects, interfaces, properties and methods. This would be tremendously helpful and not only save ESRI users a lot of time, it would be a great teaching aid, reduce the guess work, and generally speaking provide ESRI developers with a better user experience.

What's your take on this?