Imagine you were a Software Developer
Did you ever come across a situation where the data you were working with was wrong? It just does not comply to the specs. It is a complete mess. And the client does not really understand the implications because they only looked at it through some odd software (from the ugly competitor, obviously). The meta of the data sits in the mind of so many people but has never been organized and fixed (to fit into our software). Oh, maybe there are some ugly old UML diagrams that have been glued into a PDF as JPG images after resizing them beyond legibility. And the latest version you have is beta-something from eons ago.
Imagine you were a Data Monger
Did you ever come across a situation where the software just did not want to eat your data? First the encoding is wrong, then it needs a carriage return AND line feed instead of just a \n. Then it imports the core column which contains all the float values you really need as text strings. After some time you find out how to "fix" this. Until several days later you notice that the import routine cut off all the decimals in one data set. Because it came from a German colleague and interpreted the commas as thousands separators instead of decimal marks (darn German encoding). Sigh.
Who is Right?
Hacking data (designed by Matt Brooks)
Obviously both are right. But their perspectives are different - and for some reason the software developer often "wins" whilst the data monger should.
For us software engineers data is a nuisance. It never works, stubbornly refuses to "flow" into the software. And because the software is (obviously) right the data must be wrong. The good thing is that data can be "corrected", tweaked, bent and made to work.
For us data mongers the software appears to be wrong. Initially. But then the software engineers tell us otherwise plus the stack was dead expensive, looks awesomely professional and others seem to get by with it. So we start to wonder and then we start to tweak. Make the data fit into the software.
Wrongdoings!
And this is where it all goes wrong! Because software comes and goes. Data stays. Especially geospatial data. It may get old and become a historic document. Which you need badly later on when you want to show how things change over time. When you need to document that change. Software instead gets outdated and falls out of use. Data grows and becomes more complex. This is not nice but it is a reality. Deal with it. Never ever even think that you have to make the data work with your software. The software has to deal with your data. Or die. It is like trying to wear shoes three sizes too small. Well, you can cut off your toes...
Right-doings!
The data is where the money sits. This is a simple reality. Software should never be more than thin veneer. If the data is a brick then the software is the mortar. Did you ever see a mason cut off every single brick the mortar is thick?
If a tire and the rim are the data then the software is the tire mounting lube. No more. Would you cut up and reweld the rim so that the lube will help the tire slip on?
Software is nothing but a soap bubble on the rim. It must be dead easy to wash off and exchange for another brand. Because Data is important. Software is not. Software comes and goes.
Appeal to us Software Engineers
Please let us collectively get down off our high horses and accept that we are humble servants to the Data. The Data is always right. It cannot be wrong. It is Data. All that is wrong is our attitude.
Have fun,
Eight
Part II of this rant (link forthcoming) will describe some nasty effects resulting from sticking with software that prescribe you what to do.
