Have you ever burned your hands by some new and immature technology? [closed]

roadmap

I often hear people saying you shouldn't rush into adopting new technologies until they have become stable, tried and tested. There is even a joke on how it takes 3 versions to get it right. This might be the voice of real-life experience, but at least sometimes such posture is the result of complacency, resistance to change and effort necessary to learn new skills.

In my opinion however, it is crucial for success in software industry to keep the pace with the innovation. While big companies have whole departments dedicated to R&D, in smaller companies it's the development teams that have to keep up. Embark on the new technology even before it is officially out - this will give you some head-start and will help you keep up with the rest.

Here is the strategy that I try to follow whenever possible:

Be aggressive in adopting new technologies
Use early betas for experimenting and prototypes and RCs for development
Address any last minute changes to the product when official release of technology you adopted early comes out
Do not rely on some obscure open source project with 0 activity
Be sure to study but take with a grain of salt official product roadmap.

So far, I never paid the price of being too zealous to jump on some new technology train, still I reaped the benefits. I wonder if this is just a coincidence or maybe being early-adopter is not so dangerous after all?

More than inviting to a discussion on the subject early-adoption, since such issue is surely to be contentious and subjective, I would like to hear real-life experiences where adopting early new technology proved to be a serious mistake and dire price had to be paid.

Solution 1:

I can write a pretty good Java Applet. All technologies will fall by the wayside eventually, but this one had a very sharp rise and fall.

Solution 2:

I'm currently in the process of getting burned by Microsoft Office Word 2007's CustomXML support.

CustomXML allows the document to have custom defined elements that can model business data etc. For example, you could define an XSD with your custom elements, associate it with a docx file, then generate the placeholders as CustomXML tags and navigate/modify the documents using C# (or other .NET languages) and the OpenXML SDK. The benefit of OpenXML is that it decouples the need to have Office installed on a server machine for automation purposes and is an alternative to purchasing 3rd party libraries.

In short there was a lawsuit regarding Word 2007's ability to open documents with custom defined XML. From this article:

On August 11th, the company received an Office Word sales injunction ...

"This injunction applies only to copies of Microsoft Word 2007 and Microsoft Office 2007 sold in the U.S. on or after the injunction date of January 11, 2010. Copies of these products sold before this date are not affected."

Microsoft's response is to remove support for CustomXML from future versions of Word and is releasing a patch that would entirely remove this capability. Here is the link to the official update. According to this Microsoft OEM Partner Center site:

The following patch is required for the United States. The patch will work with all Office 2007 languages.

After this patch is installed, Word will no longer read the Custom XML elements contained within DOCX, DOCM, or XML files. These files will continue to open, but any Custom XML elements will be removed. The ability to handle custom XML markup is typically used in association with automated server based processing of Word documents. Custom XML is not typically used by most end users of Word.

I imagine a tiny percentage of end users and developers make use of it, so I consider that last sentence to be accurate. The problem is there's currently no word (no pun intended) on how to move forward for projects that did utilize this technology. CustomXML is the cornerstone of a large project I'm currently working on. The impact of this decision is not positive and it effectively prevents any forward compatibility as there's no equivalent alternative approach that maintains the structure that CustomXML provided.

Some of my coworkers and I have a wealth of knowledge on the topic... I guess it's good we didn't get around to writing blog posts about it as we had planned :) We've accomplished some pretty impressive feats with this and the VSTO, but this news is disappointing.

If anyone's interested in this topic here are some articles to check out:

ZDNet articles:

Microsoft loses its appeal in $200-million-plus Custom XML patent infringement case
Microsoft removes Custom XML features from Office 2007

BNet articles:

Microsoft Moves Fast, Already Has Custom XML Patch for Word
Microsoft Might Get Advantage or Pain from Order To Not Sell Word

Softpedia articles:

Microsoft Can No Longer Sell Office Word 2010, 2007 or 2003
Microsoft Dodges Office Word Sales Injunction - At least temporarily
New Office 2007 Copies Coming after Custom XML Appeal Was Denied to Microsoft - Starting in 2010

EDIT: added link to the official update.

Solution 3:

Several years ago, we made heavy use of the new SQL Server 2005 feature called Notification Services. To our dismay, that has been discontinued in SQL Server 2008. This was a serious problem, caused the software architect to question all new Microsoft technologies.

Here's some detail and some more and some more

There have also been issues with Microsoft's Entity Framework.

Solution 4:

Anybody else remember OpenDoc, Apple's idea for how all new Mac applications would be written? Didn't think so.