Shebanation

OK, I just have to post an update to my blog posting on Office XML, because my post causes some reactions from Microsoft and its friends that amuse me no end:

• First. Rick Schaut published an update to his original blog posting where he responded to my blog posting, producing a new estimate of how much work it would be to add Office Open XML support to the Mac versions of Word, Excel, and PowerPoint. I somehow missed this update when it happened, or I would have responded sooner.
• Next, David Berlind of ZDNet published an article on the “he said, she said” nature of our posts, using a baseball metaphor. His premise is that a two year old could have hit Rick’s ball (his original post) out of the park, but in the end says that not only did my ball (my post) get caught at the warning track, but that the runner got caught tagging for home. I’m not really sure who or what the runner is supposed to be in this particular metaphor, but we’ll let that slide… No hard feelings, though, David - I got a good laugh out of it, and I certainly don’t mind getting my name mentioned in a column from a much more well-known blogger, even when he calls me vicious. I do want to point out that I did warn everyone in my first blog post that I was known for having a bit of an acid tongue. Guess I haven’t mellowed quite as much as I thought.

Now, I’ll be the first to say that I was having a little bit of fun with Rick’s original post. I didn’t really believe it would take a team of good developers 150 person-years to do the work. Rick’s original estimate was ridiculously overinflated, and I used that to my own rhetorical ends. That doesn’t mean my original point wasn’t valid, though.

Fortunately, Rick has now published a more realistic estimate, one that I believe is more accurate. Here’s what Rick now has to say:

If we had to add support for Open XML to Mac Word 12 without being able to port code from Win Word, the read/write estimates shrinks down to about 8.5 man/years (44 weeks x 5 devs x 2 for read+write). As I recall, this about half of what it took to add HTML support to Word: 10 or so devs over a release cycle of 2 years. Doing the work for PPT and Excel isn’t strictly a multiple of Word, because about 30% of the XML elements are shared between the three apps. So, for all of Mac Office, I’d estimate it would take a total of about 5 devs over the release cycle to add full Open XML support starting from scratch, as part of the larger project.

David Berlind says this update refutes my argument, so much so that in his baseball metaphor the response is good for two outs instead of one. But is that really the case?

The fact is that Rick is now spinning things a bit, and his new numbers don’t really disprove my point at all. First, notice that he split the figures for Word from those for Excel and PowerPoint, and that the former figure was expressed in person-years while the latter is a count of developers. This is a common form of numerical misdirection. Since the release cycle is two years, the total effort is actually 18.5 man years [8.5 man-years + (2 years * 5 people)]. That is actually slightly less effort for Word, Excel, and PowerPoint together than he originally claimed for Word alone. (I’ll leave it to someone else to point out what this does to Rick’s original argument about why the Office Open XML converters for the Mac aren’t coming anytime soon.)

But there’s another thing missing from Rick’s estimate that I included in mine: additional resources for testing, localization, documentation, etc. As I said previously, that would easily double the amount of resources required, and that is a very conservative estimate. So now we’re back up to 37 person years.

Now in my previous estimate, I also estimated that it would be more difficult for someone else to create Office Open XML converters, because their internal document formats would be very different than those of Office. So adding that same fudge factor gets us to 46 person-years, rounded down.

That’s a bit less than a third of my previous estimate, but its still a heck of a lot of resources. Even if you choose to use the unfudged 37 person-year figure, my point about the investment required still stands: how many competitors can afford the investment of 18-23 people over a two year period to implement a check-list feature?

David, bottom line is that you scored the play wrong. Here’s how it really went down: Rick lobbed one over the fat part of the plate, I hit a fly ball to the warning track. Should have been an easy out (or two), but Rick committed an error fielding the ball. So I’m on second base, nobody’s out, and the runner scored. Still wish I knew who or what that runner was supposed to be.

(And, in case anyone missed it, I’m still having a bit of fun with this.)

Posted by Andrew Shebanow at 03:39 PM | Permalink | Comments (4)

Adobe published a prerelease version of Mars on Adobe Labs last week, and blog posts are starting to show up. I’m very happy with the response so far – most everyone who looks at it has good things to say about it. However, one of the more common memes around the Mars release is that it is nothing more than a ‘me-too’ response to XPS. That isn’t the case: Mars has been in the works since before XPS was even a twinkle in Microsoft’s eye.

The origins of Mars began way back in 1999 when Jim King and Chip Brown experimented with a PDF representation that used ZIP-based packaging of SVG page content built on Acrobat 4.0. At the time, it was known internally as PDML (for Page Description Markup Language) and later became known as XDF (XML Document Format, I presume).

In 2003, Phil Levy began work on a new implementation of the idea, with the intention of productizing the technology as part of Acrobat 7.0. Unfortunately, the feature didn’t make it in time for Acrobat 7.0, but it was present in at least one public Acrobat 7 beta release. In retrospect, getting cut from Acrobat 7 was a good thing, as the feature wasn’t quite ready for the Acrobat 8.0 release in November 2006 either :-) Seriously, though, the design did get refined quite a bit over the last year and a half. The early version of Mars used an Adobe-defined packaging mechanism, while the current version uses the packaging mechanism defined in the OEBPS Container Format, which in turn is built on top of ODF. The early version supported only a subset of PDF, while the current version supports virtually all PDF features with only a few legacy edge cases unsupported. Maintaining backward compatibility with PDF was a critical feature for Mars.

Bottom line on all this history, though, is that the Mars technology has a long history here at Adobe and is not something we just threw together as a response to Microsoft. It is, in fact, a much richer and more standards-based technology than anything Microsoft is attempting. Eliot Kimber said it better than I ever could:

After seeing Adobe’s presentation and talking to the guys from Adobe it’s clear that what they’ve done is a sincere and well-thought-out attempt to Do The Right Thing rather than a cynical recasting of proprietary stuff into markup so it’s “open.”

MARS tries to use standards as much as it can and it seems to do so to a remarkable level of completeness. It uses SVG for representing each page, supports the usual standards for media objects (bitmaps, videos, etc.). Uses Zip for packaging, and so on.

I’ll talk more about why Mars and standards in a future blog post.

Posted by Andrew Shebanow at 05:03 PM | Permalink | Comments (3)

I’ve updated my blog to use a new template, Fleur which I downloaded from the MovableType Style Archive. The actual design is by Jennifer Maloney of freshwear.ca. Thanks for making this cool style available to MovableType users!

Of course, I’m a newbie at this whole MovableType thing, so if things don’t work right, don’t blame Jennifer…

Posted by Andrew Shebanow at 04:50 PM | Permalink | Comments (1)

John Milan has written an article on Read/WriteWeb where he discusses the future of applications and the implications for google and Microsoft. In Part II, he suggests that one way google could diversify its holdings would be to buy Adobe. Just in case this is true, I’d like to be the first to say that I welcome our new google overlords. :-)

I do think he sells Adobe short in his analysis, though. HTML/CSS and .NET are not the only two execution environments that matter: the Flash Player is the most ubiquitous virtual machine-based operating environment in the world. Flash is doing well in the mobile world, and runs in cars and refrigerators as well. Flash has a one-click deployment story and Apollo makes that story even more powerful. Flex makes it easier for developers to target the Flash Player runtime. You get the idea…

Hey, maybe one day Adobe will buy google…you heard it here first.

Posted by Andrew Shebanow at 03:48 PM | Permalink | Comments (4)

Way back in October, Bob Sutor, IBM’s open standards guru, wrote a piece on his blog where he described the Office Open XML standard as a one way standard, because the format is so complex and so geared towards compatibility with legacy Office compatibility that it could never be implemented as a fully functional file format by any competing personal productivity applications (PPAs) like WordPerfect and OpenOffice. I agree with a lot of his points but didn’t feel compelled to write about it since the issue had been covered pretty comprehensively in the blogosphere.

Today, though, a couple of interesting things happened that made me want to write about this. The first is that ECMA approved the Office XML standard over IBM’s objections. That got me thinking about Bob’s original piece again. The other is that Rick Schaut of Microsoft’s Mac BU wrote an article explaining very eloquently why the Mac version of Office won’t support the Open XML file format until sometime next year. What struck me when I read the latter piece is that Rick absolutely, positively proves Bob Sutor’s point when he explains what it would take to create a file converter from scratch for Mac Word:

[…] a team of 5 developers will implement 25 handlers a week, which means that we’d have all the XML handlers written in 44 weeks. […] Nevertheless, we’ve taken a little less than a year to get the converters reading the new file format. We still aren’t writing the new file format, we have the RTF side of things to worry about, which is actually more complex than the XML side, and I’ve completely left out all of the design and coding for the intermediate representation of the file. The intermediate representation, itself, is at least 6 to 8 months worth of work.

Got that? It would take 5 developers a year to do a quarter of the work. That means the whole job is roughly 20 man-years of development time. That doesn’t include testing, documentation, or localization. That would probably double the number of man-years, at least. But it gets worse:

This is just for Word. We need additional teams for Excel and PowerPoint.

Back of the envelope, we’re now talking about 120 man-years. For Mac Office, Microsoft decided such an investment wasn’t practical, so instead they waited for Win32 Office to go final and are now porting the Win32 code to the Mac:

Lastly, can we port the Win Word converter? Well, actually, in a way, porting the Win Word converter is exactly what we have been doing, but we’re still faced with having to wait until Win Word ships before we have the final source code to merge into what we’ve already ported. Once that merge is done, then we still have to go through several months’ worth of testing and bug fixing before they’re ready for public use.

But it gets even worse! There is a lot of commonality between the in-memory data model for Win32 Office and Mac Office, since they share a lot of the same code, but doing converters for a competitive product that has a different in-memory data model would require more development time and more compatibility testing time.

Breaking out my envelope again, we’re now looking at 150 man years to do the job for a competitive PPA. How can competitors afford to make that level of investment? Novell says they will support import and export for Open XML with financial and technical help from Microsoft. Corel says they’ll do it too. Guess we’ll need to wait and see how successful they’ll be at maintaining fidelity and compatibility, though given what Rick has to say, I’m not super confident.

Posted by Andrew Shebanow at 01:26 PM | Permalink | Comments (9)

As anyone who reads digg, slashdot, and/or techmeme knows, yesterday Microsoft released new versions of the Expression tools and the first “CTP” of the WPF/E runtime.

One of the more interesting posts made about the announcement was Robert Scoble’s explanation of why “Microsoft targets Adobe”. In it, he talks about how in the early days of longhorn, the UI design folks created all kinds of whizzy demos in Director, and that this became a problem when those prototypes had to be turned into real code. Why was it a problem? Scoble says:

Why? Because executives bought into the Flash and Mirrors song and dance too. They thought what they were seeing was possible.

The problem was, developers weren’t involved. Only people who studied interaction, design, and Macromedia Director.

Problem is, anything you create in Director has to be thrown out and rewritten in C++ (if you work on the Windows team).

That meant a whole bunch of time is wasted, plus it’s very possible that what you are dreaming of is simply not possible. It’s also possible that development teams, that don’t understand interaction design, will change your “experiences” and totally munge things up.

So, could Flash ever be “force fit” to be the UI of Windows? Not according to the engineers who’ve studied the problem.

They needed a system that could be used to design real pieces of Windows, if not the entire UI, and handed off to a developer, or team of developers, without having to have the developers touch the UI at all.

What Robert Scoble is saying here is important, in that it demonstrates the fundamental weakness in Microsoft’s strategy: WPF, WPF/E and Expression Blend were all designed first and foremost to address the designer-developer workflow as practiced in the Windows group at Microsoft. And based on what Robert Scoble wrote above, and on what I saw when I worked at Microsoft, this is a workflow that is all about having designers fit in with how developers want things to work. That’s why they put so much focus on things like having Expression Blend use the same project format as Visual Studio, having it work with Visual Studio’s version control mechanism, and so forth. When was the last time you heard a designer put any of those things near the top of their wishlist?

By contrast, Adobe feels that designers developing modern, interactive applications (whether using Web 2.0/Ajax or RIA technologies) want to build workflows that are first and foremost about delivering great designs to your clients. Those clients may be developers, but they might also be a corporate marketing department, or an online or offline content publisher, or any one of a zillion different content consumers. Adobe has designed Creative Suite, Apollo, Flex, and so forth to enable all these workflows, in a way that lets designers focus on what they do best.

Personally, I think Adobe’s choices show that we have a better understanding of designer needs. Of course, that doesn’t mean we don’t have lots of room to improve. I’d love to hear what real designers think, so please comment!

Posted by Andrew Shebanow at 03:30 PM | Permalink | Comments (4)