Brian Jones: Open XML Formats : Spreadsheet performance - Shared Formulas

via a comment to the above linked post, Biff (unfortunately I don’t have a link (Biff, if you happen to read this and have a preferred link, let me know and I will update this post)) has this to say in regards to the first quoted piece from Mike:

“Since this blog is about the so-called power of Xml and associated API, how do you achieve this without a running Excel instance?” — Mike

Perhaps invest in better coders? This appears to be very sensible and straightforward optimization, not rocket science by any stretch of imagination. C’mon, do you believe every user out there must suffer from performance drops because your coders cannot get their act together? Bleh.

I have to say that I totally digg someone who can say it like it is…

Folks, software development is not an easy task. We all do, or at very least should understand this, right?

There are a TON of people on this planet (I like to consider myself one of them) who have made it their life’s work to become the very best they can be at, in many cases, a VERY difficult task that involves understanding how to make the most efficient, feature packed, bug free software they can. While its possible to abstract away a lot of the difficulties and allow for a broader base of folks the ability to develop software, the further the abstraction, the more difficult it becomes for the processor to efficiently process all of the layers necessary to ensure that the authors intent is properly rendered.

If you happen to read Brian’s blog with any regularity, you will discover a process taking place that involves a consistent effort at weighing the cost/benefit of making it easier for the developer to implement extensions, while sacrificing as little performance possible for the end user. Quite frankly, as both a user and a developer, the fact that a team of experienced, dedicated folks are developing a format that other folks can openly implement without cost brings me a WHOLE LOT of reassurance that the end result is going to be a solid balance between extensibility, programmability, and performance.

These are WONDERFUL things! Personally, I’m glad to know that the right people are in the right positions and are making the right decisions based on a constant balancing act of end user performance, and developer extensibility.

That’s not to downplay ODF in ANY regard. I know several of the folks that worked on the ODF spec, and their best of breed folks, just like Brian and the rest of the folks at MS, as well as the members of ECMA, involved with the process (of which, by the way, anyone can join and take part in if they so desire…) developing this format.

But the objective has been different. ODF was purposely developed to be the way it is… Lightweight, less definition, and as such leave the door wide open for extensions to be developed. Office Open XML is being designed to support the existing base of Office features (which, quite frankly, ODF matches the features of Oo.org quite well, so in many regards, ODF does the same thing, but for a different product) while implementing a core set of defined extensibility features without placing ANY limitations on how we can extend it to implement our own desired features while making our jobs as developers as efficient/productive as possible without sacrificing the customer in the process.

As Rick Jelliffe recently states:

I think there is substantial value in a standard XML format for MS Office documents even within organizations that will mandate ODF for interchange and archiving. The availability of the alternatives reduces the need for ODF or Open XML to be the one true interchange format.

With all of the effort going into the development of a user-centric file format, that also allows for developer extensibility, the end result, as Brian puts it quite well in this same linked post:

I admit that it makes development a bit more difficult, but as I said before, we kind of had to take the training wheels off and actually think more about the end users as well.

If your question is: As a developer, will I have to learn more than I already know to make efficient use of the Office Open XML format?

The answer would be:

Yep. Just like Ruby, or (in my case) Python, or any other new language that you might be attempting to learn more about, to make progress, you are required to make an effort to learn something you don’t already know to make proper use of the Office Open XML format.

Isn’t that what technology is all about… Progress?

[Thanks for the quotable comment, Biff! You brought a smile to my face for sure :D]