As I’ve mentioned a number of times, I’m a big proponent of keeping solutions simple. While doing some reading over the weekend, I ran across this presentation (pdf file) by Neil Ford of ThoughtWorks. This was his keynote at eRubyCon in August 2008.
Along with a brief history of software development, and his theory that software productivity would massively increase if the worst 30% of developers were fired, he talks about the relationship between essential and accidental complexity and summarizes it like this:
- Essential Complexity: We have a hard problem
- Accidental Complexity: We have made a problem hard
I think this is a really clean way to describe the difference – sure some software projects actually are complex. But many are not, and the challenge for developers and designers is to keep both kinds of projects as simple as they can be. If we use that as a guide, the resulting software will be much easier to build, debug, test and maintain.
Geospatial applications are inherently more “complex” than standard “forms over data” applications. Regardless of the business logic being applied, at the very least we have that pesky geometry to deal with. Add to this, complex spatial API’s, limited spatial support in many “forms over data” power tools (NHibernate, SubSonic, Entity Framework etc), and systems that believe that they should control ALL the data (yes geodatabase I’m looking at you). Thus, keeping things simple is even more important, and I’d go as far as saying it’s crucial for our industry.
