Tuesday, July 11, 2006

The seduction of The One

As a programmer, the notion of The One is very tempting to me. Let me explain.

When designing code, you come across many different elements that have to be coordinated, manipulated and routed. Data and state information may need to be transmitted to other parts of your code, other programs on your system and sometimes even remote systems. Usually you come up with a model of how these different parts will interact with each other and you can make simplifications in the code that will enable enormous flexibility and scalability. For me it also gives me a good feeling inside knowing that I've just created a quality tool that will make the project easier in the future. I don't know much about eastern philosophy, but perhaps this is a Zen or Tao feeling of "rightness" in the code. Anyone who has spent much time programming will know this feeling.

Having an abstraction that provides a single interface from many code state sources to many state consumer destinations is something that, when done right, reduces the complexity of the code by an order of magnitude. This is "The One." A single representation of an idea that interoperates with all or most of your code making state changes nearly effortless.

However in real coding, things are never that simple. There are always problems with dependencies, synchronization and sometimes it is like trying to fit a square peg into a round hole. There is a saying attributed to Einstein along the lines of make things as simple as possible, but no simpler. This rings true again and again when coding. I have wasted countless days, weeks, even months trying to create an abstract superset of functionality that the project would just fit in nicely and have plenty of room to expand, wouldn't that be nice? To go from being an expert programmer to a master code craftsman, one must learn to avoid this pitfall at all costs. Nothing eats up more time than writing code that winds up never being used. We all throw away big blocks of code when a better replacement comes along, that is unaviodable, but in the planning stage of a project is where an over-enthusiastic programmer can really mess things up with a "simplification." There are local maxima and minima in programming and going over a little hill of work will sometimes put you in a state where things are much easier. More often however, doing a little foundation work to smooth the interface out will leave you where you started or even worse, make things more complex.

To tie this to my recent post about the shapedb format, the ability to add raster data to the shapedb is certainly nice and simplifies distribution for related data. However the need that brings rise to the shapedb format is not a convenient repository for data, but the processing overhead required in extracting and converting data into something useful from shapefiles. Now that the madness Hopefully I've just saved myself a few days of trying to make a nice "geodatabase" format that fits all sizes, I'll just focus on vector data for now.

2 comments:

Best essay writing service said...

This is also a very good post which I really enjoyed reading. It is not everyday that I have the possibility to see something like this.

Kate Morey said...

Very interesting article, I enjoyed reading it. Thank you. Also, check out custom writing service called handmadewritings and get the best papers.