When a new version of a software is released, the old version lives for a while and its creators usually care about supporting it. Yesterday, after reading about the release of Cairngorm 3, it’s clear that Adobe Consulting ignores this rule.
For those who are not following Cairngorm evolution, I want to remind that there was a framework called Cairngorm 2, that was a library of classes (built on Model-View-Controller architecture) to be included in the Flex application. I never agreed with the architecture of Cairngorm 2 which was acting as a Crazy Glue and lead to generation of monolithic applications based on global singletons. People who follow my writings or were attending my presentations at various conferences know that during the last four years I was openly stating that Cairngorm 2 has more cons than pros. For example, here’s the just one of of these occasions – a video of the panel on enterprise frameworks at Adobe MAX 2008 (after this blog, I doubt that I’ll ever be approved as a MAX speaker again).
Now, when I looked at the design of a product that’s now branded as Cairngorm 3, it’s clear that Adobe assigned to this project the right engineers (i.e. Alex Uhlmann) and there is hope that this methodology (it’s not an MVC framework any longer) may produce or include useful component libraries.
My first problem is that the Cairngorm 2 has literally disappeared from the face of Earth (the only trace found is the site cairngormdocs.org that has some old documentation).
My second, and more serious problem is that Adobe Consulting up till today has never made a statement that selecting Cairngorm 2 was a wrong path. There are lots of enterprises that some time ago started using Cairngorm 2 (recommendation by Adobe Consulting) just to find themselves with a large monolithic application at hand that took long to download and was difficult to modularize.
A couple of years ago, I lead a large enterprise project for a customer that I won’t name, but will provide some relevant technical details. When I joined, the team was already 5 months into the project. This consumer facing application was producing one 5Mb SWF file. Just recompiling the application in Flex Builder was a lengthy project. I started to look at ways of modularizing this application so the first screen would come up sooner than 90 seconds for customers sitting on DSL connections.
Sure enough, the project has been built with Cairngorm 2 by advise of some engineer from Adobe Consulting (not to be confused with Adobe Flex team). The Cairngorm’s global class FrontController is expected to be a registry for all possible events that travel through the system let alone tons of classes and boilerplate code written just to support that life cycle of the framework itself.
My first suggestion was to start modularization with removing Cairngorm. They asked, “How much?” It would take two man-weeks worth of work, but they didn’t have time for this. To make the long story short, we had to modularize the application in a non-kosher way – the main SWF had a knowledge about all events in every module. Changes in a module’s code can lead to changes in the main applications. Tight coupling in action.
I’m sure there are lots of enterprise teams that were similarly misguided and were marching in a wrong direction under the Cairngorm 2 banner.
With the release of Cairngorm 3, the Cairngorm 2 has vanished. I’m sure, if you’ll hire a private eye, you’ll find its code (has not been updated from about three years) in some SVN repository. But this is not how the new version of the enterprise software should be released.
I’d like Adobe Consulting to state loud and clear, “If your team started development of a large enterprise project with Cairngorm 2, please stop. This was our mistake, and the sooner you switch to Cairngorm 3 or any other lighter framework the better.”
Will it happen? Let’s wait and see.
P.S. The views and opinions expressed in this blog are purely my own and don’t represent views of my employer