I’m a developer who frequently advises senior management on technical policy so I routinely keep one foot in techie-land and one foot in business-land. This position keeps me “squinting” at both and “smelling” both to insure that technology is built right so it can be applied right.
By now, you all know that Jeff Atwood wrote a controversial article calling XML a “tax”. The very title of the article is spin and a one-sided developer’s perspective. Why one-sided? He is not considering the business value of XML. By trying to squeak out a tiny bit of time-saving and save a few characters per line he would be throwing away a robust standard that offers application-independent data, a simple syntax, and a wealth of tool support. From a business perspective - stability and reliability beat your minimal efficiencies. Wake up and stop thinking like a techie! We easily forget, and I have been guilty of this many times, that technology serves business and not the other way around. YAML? Are you kidding me? Computers are fast and disk storage is cheap so I really am not interested in such minor efficiencies. Using indentation to distinguish hierarchy in data? That is very risky! This is not a programming language like Python that is guaranteed to be run through a compiler. In the data you must have explicit declaration of syntax NOT implicit. Again, if you are thinking like a developer your brain says “hey, I can save those angle brackets and not have to type them” or “I can save that closing tag so I don’t ‘waste’ my precious time.” Please … those angle brackets and that closing tag make the data demarcations explicit. That is more important than a developer saving five keystrokes per line. So, I don’t know whether Jeff is a senior developer or not, but he needs some more exposure to the business side of the house. Developers re-breathing their own air is dangerous.
The key point here is that stability and reliability (like the explicit syntax of angle brackets) over minor developer efficiencies wins every time in the minds of business executives. And they are the ones who pay the bills! Violate this principle and you, or your business, will lose. As an interesting corollary for developers as the customer, here is an interesting ZDNet article on how Microsoft may be losing the trust of developers due to lack of stability in its development platform. In this case the developers are the customers and they have to choose a development platform. If you keep switching positions because the new group of developers Microsoft hired wants to do it differently for “small efficiencies”, you lose the trust of your customer base who get tired of the tail wagging the dog. The perfect example of what not to do is the Ribbon interface in Office 2007 - I just witnessed a large government agency with many, many employees delay pushing out Office 2007 because Microsoft’s office developers threw out years of people’s knowledge of the menus and layout in Office 2003 - and for what? No gain from a business perspective that’s for sure because creating word documents or slide presentations is not rocket science. So if Word 2007 reduces worker productivity by any appreciable percentage that is a direct hit to the bottom line.
So, small developer efficiencies must not derail hard-won business value. Application-independent data with explicit syntax that everyone is familiar with (think HTML) is a gold-mine of business value. For any developer to be ambivalent about that is downright naive. Sorry if that offends some, but developers develop to achieve business value and not technical value. The days of “I saved 8 key strokes in my data”, like saving “8 bytes in 64k of memory” are over.