The lower bound is very low, true. The distance between that lower bound and what's perceivable by a user, however, is generally substantial.
Of course it depends on the application. There are certainly some applications where engineering the data stream to minimize client-side parsing and transformation time will be perceivable, and where the payoff in responsiveness is worth the development cost of that engineering.
The shopping-cart application in this article sure as hell isn't one of them, though.
Here we have a detailed, in-depth article about client-side browser XML processing that doesn't once mention XSLT. If you're writing JavaScript to transform your XML responses into updated client-side HTML by manipulating your browser's DOM, you probably should be listening to those who are recommending nonstandard-but-terse formats for data interchange.
And while we're on the subject of terseness: complaints about "bloated" XML are meaningless outside of a context that takes the application's overall bandwidth requirements into account. Is an XML document bigger than a binary data stream? Sure. Is this significant? Depends on your application.
See, for instance, Jerome Groopman's article about patient simulators for surgeons in this week's New Yorker.
"Virtual reality" is mentioned only once (in the parenthetical aside in which Jaron Lanier makes a brief appearance). There aren't any head-mounted 3D displays. A fair amount of what shapes the virtual reality is other people talking (e.g. the "patient's" voice is actually that of the doctor running the simulation).
But the article makes it crystal clear that the surgeons (and surgeons in training) who are using these simulators find them pretty freaking "immersive."
I've spent nearly 20 years selling COTS systems to the government.
You know what? The government screws up the process of buying and implementing COTS software every bit as thoroughly as they screw up the process of building custom software.
Mr. Carr's op-ed piece notably fails to mention salient facts about the event that occasioned it. Why did the FBI cancel a $170 million electronic case-management system? "Um...because they should have bought a COTS system!"
No. If Mr. Carr troubled himself to read the NYT's article on why the project got cancelled, you can't see it from his piece. Topping the list: difficulties in getting disparate entities to come to agreements on how the sensitive information they collect should be shared.
Does this sound like a problem that could be better addressed by buying COTS software? No, it does not. And it isn't.
Does it sound like a problem that should have been resolved before, say, spending money on software? Why, yes, it does. It sounds like a mighty important stumbling block. And yet it wasn't.
This situation has nothing, not one little thing, to do with COTS-vs.-custom.
Absolutely nothing in the story of this system's cancellation surprises me, nor any of my colleagues. It's exactly like the California DMV's cancellation of its $70+ million system upgrade back in the late 1980s. Or the upcoming cancellation of their $250+ million California Case Management System for the courts. (That one may take a couple of years, but watch for it. It's coming.)
The government's process for procuring enterprise software is deeply, fundamentally broken. (I shouldn't say "the" government; my experience encompasses county, state, and federal governments in the US, as well as provincial and federal government in Canada.)
Watch carefully, for instance, to see who at the FBI is going to lose their jobs for misspending $170 million. Hm, could it be...nobody?
How can this be? How can it be nobody's fault that $170 million of your money and mine got flushed down the toilet? The answer is: it's nobody's fault because from day one the project was structured so that when it failed it wouldn't be anybody's fault.
Here, for the benefit of Mr. Carr, is the difference between the FBI buying a custom solution and the FBI buying a COTS solution: If the FBI had bought a COTS solution, they would have spent $170 million on licensing, configuration, and implementation. Then they would have cancelled the project.
Slashdot Mirror
The lower bound is very low, true. The distance between that lower bound and what's perceivable by a user, however, is generally substantial. Of course it depends on the application. There are certainly some applications where engineering the data stream to minimize client-side parsing and transformation time will be perceivable, and where the payoff in responsiveness is worth the development cost of that engineering. The shopping-cart application in this article sure as hell isn't one of them, though.
Here we have a detailed, in-depth article about client-side browser XML processing that doesn't once mention XSLT. If you're writing JavaScript to transform your XML responses into updated client-side HTML by manipulating your browser's DOM, you probably should be listening to those who are recommending nonstandard-but-terse formats for data interchange.
And while we're on the subject of terseness: complaints about "bloated" XML are meaningless outside of a context that takes the application's overall bandwidth requirements into account. Is an XML document bigger than a binary data stream? Sure. Is this significant? Depends on your application.
See, for instance, Jerome Groopman's article about patient simulators for surgeons in this week's New Yorker. "Virtual reality" is mentioned only once (in the parenthetical aside in which Jaron Lanier makes a brief appearance). There aren't any head-mounted 3D displays. A fair amount of what shapes the virtual reality is other people talking (e.g. the "patient's" voice is actually that of the doctor running the simulation). But the article makes it crystal clear that the surgeons (and surgeons in training) who are using these simulators find them pretty freaking "immersive."
You know what? The government screws up the process of buying and implementing COTS software every bit as thoroughly as they screw up the process of building custom software.
Mr. Carr's op-ed piece notably fails to mention salient facts about the event that occasioned it. Why did the FBI cancel a $170 million electronic case-management system? "Um...because they should have bought a COTS system!"
No. If Mr. Carr troubled himself to read the NYT's article on why the project got cancelled, you can't see it from his piece. Topping the list: difficulties in getting disparate entities to come to agreements on how the sensitive information they collect should be shared.
Does this sound like a problem that could be better addressed by buying COTS software? No, it does not. And it isn't.
Does it sound like a problem that should have been resolved before, say, spending money on software? Why, yes, it does. It sounds like a mighty important stumbling block. And yet it wasn't.
This situation has nothing, not one little thing, to do with COTS-vs.-custom.
Absolutely nothing in the story of this system's cancellation surprises me, nor any of my colleagues. It's exactly like the California DMV's cancellation of its $70+ million system upgrade back in the late 1980s. Or the upcoming cancellation of their $250+ million California Case Management System for the courts. (That one may take a couple of years, but watch for it. It's coming.)
The government's process for procuring enterprise software is deeply, fundamentally broken. (I shouldn't say "the" government; my experience encompasses county, state, and federal governments in the US, as well as provincial and federal government in Canada.)
Watch carefully, for instance, to see who at the FBI is going to lose their jobs for misspending $170 million. Hm, could it be...nobody?
How can this be? How can it be nobody's fault that $170 million of your money and mine got flushed down the toilet? The answer is: it's nobody's fault because from day one the project was structured so that when it failed it wouldn't be anybody's fault.
Here, for the benefit of Mr. Carr, is the difference between the FBI buying a custom solution and the FBI buying a COTS solution: If the FBI had bought a COTS solution, they would have spent $170 million on licensing, configuration, and implementation. Then they would have cancelled the project.