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.
Before I go - kudos to Norm Walsh and Eric Larson for their excellent commentaries on this same subject. We have different perspectives on the issue but some of the points are similar.
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.
Excellent article, Michael!
Wanted to treat this as a separate comment because, overall, I believe your article is spot on,
>> 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.
My comment got cut off (and I know why). Please feel free to delete my last one.
repost: Wanted to treat this as a separate comment because, overall, I believe your article is spot on,
>> 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.
I would argue that -- based on the success of Office 2007 in the marketplace -- that while some government agencies and corporations might hesitate to adopt Office 2007, more people are attracted to it than repelled from it. This was a bold move by MSFT, as was the adoption and standardization of an XML document format in DIS 29500. I personally believe it was the right move -- in both directions -- and one that improves the state of the art as a whole.
That said, I do agree that you need to be *extremely* careful when it comes to application usability and supposed increase in productivity. In this case, however, I believe MSFT is in the right even though there are going to be some edge cases where others feel differently.
Brilliant post, man. This is where I will point every anti-XML fanatic to :-)
Great article. I frequently annoy other developers when I preach to them the virtues of appealing to business users. Technology is here to solve their problems, so if we want their buy in for decisions, we need to present them in terms of business value. That's the difference between leaving a meeting happy and leaving a meeting rolling your eyes about how everyone else "just doesn't get it".
Hi David,
I agree with you on the OOXML format. I have been recommending/pushing for that from Microsoft a long time. Folks may believe they handled the ISO process wrong but in the big scheme of things going XML as the default was the right thing for them to do and I congratulate them on that move.
The ribbon interface though I cannot agree with because I still do not see what good it brought. I am much less productive on Office 2007 then 2003. And I have heard the same complaint from many people. So, was it really bold or was it foolish? I currently believe the latter because I don't see the ribbon interface as an improvement. Different, yes. An improvement - I don't see it.
Best wishes,
- Mike
Hi Griffin,
Thanks for your comment and please keep fighting the good fight. It may not be a popular position - but I am convinced (as you are) it is the right position.
Best wishes,
- Mike
I really don't get you here. So senior management both cares about the data format being pushed through your middle ware and knows XML to be the best solution? Wow, over here we have senior management that cares about financials and little else. But moving beyond that, it seems your main point is:
From a business perspective - stability and reliability beat your minimal efficiencies.
So how exactly does XML provide you stability & reliability?
Also you state:
Using indentation to distinguish hierarchy in data? That is very risky!
How is that more risky than remembering to close twelve tags in the right order at the end of a record?
And finally, back to your main point:
"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."
Good business executives don't give a damn how you represent your data as long as your solution works. Period. They have way more important things to worry about. Any executive who would "recommend" XML or any other technology are the types who get their advice from Gartner and I recommend running the other direction because sooner or later that ship is going down in flames.
Hi Pat (or is it Mac?),
You are correct in that senior management probably does not know about XML (nor care about it) but they should know the benefits of application independence (no vendor lock-in), widely adopted standards (stability), and robust third-party tool support (speed of implementation). XML provides stability as a well-known and proven standard and reliability because it is simple and straight-forward to implement.
On indentation versus closing tags, closing tags are more explicit. Also, many editors will highlight problems with the syntax -- which has more supporting editors XML or YAML? Which has supporting commercial editors?
As for business executives not giving a damn about how their data is represented is changing (and should change). You are probably correct that right now most executives don't know much about their data. Since Sarbanes Oxley, other regulations and eDiscovery, many are learning that it is in their best interest to know about their data. Including the format, the metadata (for eDiscovery) and its quality. So, I would say if you are recommending that they not care about their data's format than you are giving bad advice.
Regards,
- Mike
You are completely, totally wrong about this.
What you call "minor inefficiencies" are major factors and the fact that you call them minor belies your lack of development experience. First, imagine a computer which serves as a radio base station say, which cannot fail because it is miles away from anywhere and serves tens of thousands of cell phone customers. This computer boots in two seconds, has a stand-by kernel so it can stay up even after a kernel panic, runs fault-tolerant software in erlang for example which can handle massive concurrency. Now you want to use XML? Gigantic, slow, space hogging XML files?
Sure, if you want to store your cute little internet address book, go ahead and use XML. But otherwise you need a real data serialization solution.
You also say: "Using indentation to distinguish hierarchy in data? That is very risky!" Are you kidding? What exactly is the risk? Isn't XML text? Of course it is, so it is no more explicit than any other text. The computer doesn't care about angle brackets or spaces, they are represented as numbers to the compiler - so why not use something efficient that programmers can read?
Unfortunately this post shows how little business people understand about computers, but on a happier note, YAML is widely adopted and growing so Michael it may be time to start learning how to use it.
Hi Jeremiah,
Interesting post. Let me address each of your three points.
First, on efficiency. Just so you know, I have a decent amount of development experience (just to get that out of the way); however, I have not developed real-time applications like the one you discuss as your example. On the other hand, I have developed from performance intensive simulations so I do know a few things about optimization. So, are you telling me that YAML is suitable for real-time applications. If they are that performance-sensitive I would think that a binary representation would be the most appropriate. People have raised the performance issue against XML for years. Fortunately, if Moore's law keeps holding, every year that becomes less and less of an issue. But we are actually getting off-course here because the post is not discussing computer processing efficiency it is discussing "human productivity" efficiency. Specifically, saving some time typing. So, your example is actually an apples to oranges comparison because I was talking about minor efficiencies in terms of developer's time not in terms of processing speed.
And in general, a strict performance requirement is a valid reason NOT to use XML. Having said that, I think such a strict performance requirement needs to be proven and not just assumed. Obviously a real-time application is a good justification.
On indentation, my main point is that it is easier to make a mistake with indentation than with closing tags because closing tags are explicit demarcation of an ending boundary. This is a debatable issue but I have seen many examples of programmers that sloppily indent source code to make me believe this would be a problem.
I don't really get your last point about business people not understanding computers. Unless that was just a parting dig to end the post. If so, it is not really necessary because we can debate the issues without personal attacks.
Best wishes,
- Mike
@Jeremiah,
Your response is quite possibly the dumbest thing I have ever read.
>> YAML is widely adopted and growing so Michael it may be time to start learning how to use it.
YAML is widely adopted? You've never written a line of code in anything other than Ruby, have you.
Wow. Just wow.
I recently implemented a large enterprise system: Rails on the front-end for web applications, and a series of message driven Java applications that interface with a large (serious, incredibly important) ESB for a mega-corporation. We started down the road of using YAML to send TextMessages through ActiveMQ. ActiveMQ has a stomp protocol which is very easy to integrate with something like Activemessaging.
It was all going swimmingly until we hit upon more than a few problems/bugs in the initial versions of JvYAML. I won't go into these in detail, but I will say that it cost us multiple days of effort just to diagnose the problem, and, in the end we ended up compromising our own data structures (in both Ruby and Java) to make up for the fact that transforming between objects and YAML isn't always the most straightforward problem. (we were running into screwy character set issues and problems capturing nest data structures)
If we had standardized on a simple XML format for our text message from the beginning, we would have saved ourselves a few days of madness/effort, and we would have been none the worse in terms of technology. While I agree with some people who wish that things like a Maven POM had a lighter syntax (read YAML), I also can see the other side of the equation.
Hi Tim,
Thank you for sharing your experience. It is very relevant to this discussion.
Best wishes,
- Mike