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

Question

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

Answer 1

Mozilla XULRunner.

It was Adobe AIR, before there was AIR. We wrote our Human Resources Management system using it. At the time XULrunner was "just about" to released as the underling engine for FireFox, so we expected that all we would have to do is make sure our users had FireFox installed.

2 years into the project, and right before deployment, a new XULrunner came out that completely broke all of our code, and a Firefox deployment was nowhere in sight. We ended up deploying on our older version with a dedicated desktop installer and have been using it ever since, without the benefit of security or performance updates because we would have to re-write too much code to be compatible. Despite that it has been a very successful project with our customers.

We're now re-writing the app to run on Ext which is the new hot thing for us but seems to have more community support, and offers commercial support if we really get stuck on something.

Answer 2

For lacking market presence:

• Google's Go
  • Poor toolchain, lacks integration with popular compilers and C.
• Python3000
  • Lacks must-have features: Iterators, cleaned up internals and tidier interfaces are nice for us hardcore users, but the majority want performance, and this hasn't been delivered.
• C++0x
• C99
  • It's been 12 years, and no mainstream compilers fully implement this. Popular projects and niche architectures remain on C89 to be safe.

For poor quality:

• Windows Vista
  • 'Nuff said.
• Perforce
• C++

For lagging behind upstream:

• PyGTK on Windows
• MSVC C support

Note that my listing these technologies in no way suggests that they're no good, I'm a huge fan of all of these (except the poor quality ones). My opinion on being burned by these technologies is first hand (usually me trying to push them as replacements for existing technology, or simply running into barriers after a significant investment has already been made.

Answer 3

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.

Answer 4

64 bit Carbon APIs on Mac OS X: I didn't get burnt personally on this, but I have a friend working for a big software company that spent a year converting almost all of their code to use the 64 bit Carbon APIs only to find out at WWDC that those APIs were no longer going to be made available.

Answer 5

In my opinion however, it is crucial for success in software industry to keep the pace with the innovation.

This doesn't answer your specific question, but, there's a book called Crossing the Chasm that might interest you.

Answer 6

The TurboGears web framework

I had a web app to write and jumped onto this (having heard about it from a friend). I wasn't really aware of the alternatives, didn't know MVC properly and wasn't aware of the alternatives to the various 'standard' components (eg. SQLAlchemy instead of SQLObject). While the documentation and general state of the project is far better than it was when I got my hands dirty, I ended up with a huge application that relied on 'tricks' to bypass some of the magic features and had lots of undocumented features in it to meet the deadlines. It became a maintenance nightmare and I really wish I had taken the time to build something simpler with plans for a rewrite if the requirements changed.

This was 1.x series which has been deprecated now for the Pylons based 2.x series. As you can imagine, the core team itself decided on a rearch but I was stuck with a legacy application which I had to maintain.