One size fits all is just another way to say it doesn’t fit anyone very well

It’s election day here in the United States. Perhaps it is in that spirit of change that I write this post. More likely it is a rant in frustration to developments I am seeing within the Flex community, but here it goes.

Here is my fundamental assertion: Anyone who thinks that every problem can be solved in the exact same way is someone you should ignore. Problems are unique and hence solutions need to be unique.

Within the Flex community it is popular to either be pro or anti Cairngorm. I myself have pointed out frustrations with it in the past, but I would like to take a broader point here as this post is not about technology, it is about people.

Cairngorm is a way to solve a problem. Actually, it is a good way to solve a very specific problem. The issue is that it is not the best way to solve every problem. I have no issue with Cairngorm but I do have a problem with Cairngorm evangelists.

I have worked on many projects where Cairngorm is an appropriate solution and I have found no desire to remove it, but I have also worked on a plethora of projects where it is the wrong solution. Unfortunately, many times this technology decision persists to the detriment of the project.
Since some of you aren’t you going to believe that there is a project where Cairngorm isn’t the right solution, let me provide an example.

We have a new client attempting to develop a component framework (effectively an extension of Flex). Those components will be reused by other customers in the field to build applications. They were trying to use Cairngorm to build their component framework, meaning they were calling Cairngorm events from inside of List controls, etc. This is not the right use for Cairngorm, yet they are adamant to continue. Why? Well, because Adobe said so.

<EDIT> When I say “Adobe said so” in the previous paragraph, I am not attempting to say that they declared to this customer a specific engineering solution. My point is more about how the collection of Adobe’s offerings and words are perceived by people learning Flex. Sorry for any miscommunication on that point. </EDIT>

At WebDU earlier this year Robin Hilliard of Rocket Boots asked me, ‘why is it the world versus Cairngorm.’ I answered at the time that Adobe advocates it so strongly, but I didn’t really have an eloquent answer. I do think the answer it correct. Right now, the only ‘advanced’ Flex curriculum from Adobe is about Cairngorm. The only framework I can find mentioned on Adobe’s site is Cairngorm. Peter Martin of Adobe Consulting announced a Cairngorm plugin for Flex Builder, and Adobe consulting was kind enough to tell this client that every single Adobe consulting customer uses Cairngorm and given their wild success, it is clearly the right way to go.

Wrapped up in that final statement is my core issue: First, unless you truly understand the problem a customer is facing you can’t possibly recommend a solution. At least you can’t do so and still call yourself an engineer in my book. However, does anyone truly believe that Cairngorm was the perfect solution to every single problem ever encountered? That there was never a better approach to be had? I personally have trouble with that.

I have had this discussion with others in the Flex community and likely used this analogy but here it is again for good measure. Software is a strange version of reality. In the real world you might admire a beautiful piece of sculpture. It is unlikely that your opinion of it would change drastically when you learned the brand of chisel used to create it. In the software world, I hear this ridiculousness all the time. The tool used has become more important than the end result. That is sad.

I know this post sounds like a bashing of Cairngorm and the people who use it. This is not my intent. I have a lot of respect for a lot of these people. The point of this post is simple. Problems require solutions. Sometimes you can start with an existing framework and work from there. There are several valid ones in the Flex world, but if you close your mind to possibilities outside of a single choice, you are harming yourself and the project.

Rant complete,
Michael “MVC isn’t always the right solution” Labriola


    I tend to agree. I’ve done some projects where Cairngorm was a really good fit. Others, not so much.

    Using Cairngorm to develop a component framework is insane! Amen. I like Cairngorm as well, but not for everything.

    Michael; so I just want to address a couple of points here…just because Adobe Consulting contributed and stands behind Cairngorm, that’s our contribution and our knowledge sharing, it’s not our way of saying "everything else is wrong, and this is the only way". You will never find us standing up and stating this either to customers or community…you will not find us bashing other frameworks, or being drawn into conversations of "Cairngorm is better than X". I would absolutely agree that a component framework is not the place for Cairngorm; however without the details and the context of the particular conversation it’s hard to defend….but I would imagine that if Adobe Consulting have been engaged in these conversations with a customer about Cairngorm, and that customer is also building a component framework, the 2 conversations are not necessarily linked.

    Finally, with regards to us continuing to announce plug-ins and additional initiatives around Cairngorm; these are in response to a community of users who do recognsie when Cairngorm does and doesn’t work for them, and when it does, want to benefit from the productivity enhancing tools and techniques that we’re using. I can’t apologise for a willingness to invest our time and effort in sharing these contributions with a wider community.

    Cairngorm is not one-size fits all, and we would never advocate so….in fact, my most popular blog post is entitled "Why I think you shouldn’t use Cairngorm" (you’ll find it on google) and I encourage that teams think for themselves, understand the problems, and then consider whether our solutions that we offer as open-source are applicable or not.

    I’m not sure what you’d like instead; but I’m happy for you to reach out with suggestion.




    I appreciated your response and I am going to reword something in my original blog post because of it. I didn’t mean to imply that Adobe directly recommended this customer use Cairngorm, so I will make that clear.

    My point isn’t anti Cairngorm at all. What I think is difficult to see from inside of Adobe, however, is that things like the Adobe curriculum, etc. provide a de facto endorsement of this particular framework. When users and teams are new to Flex they are looking for Adobe’s opinion on how to proceed and they immediately find it here.

    Unfortunately they often find it without the right context or enough understanding of the Flex to know what might work for their particular problem. It becomes a scenario of the world looking like a nail when you have a hammer.

    I know and have previously read your blog post on when not to use Cairngorm. I know you would agree that Cairngorm solves a particular problem well and that it is not for every use case. What I am trying to get across here is that the overall message coming from Adobe is not perceived in that way. The new teams I work with perceive Cairngorm as Adobe’s recommendation of *the* one true way to every build an app.

    Whether that is the intent or not, that is how the message is being received, at least by my sampling of customers,

    Thanks for the reply,

    Let’s face it… Cairngorm is the oldest and most widespread framework, it is no wonder why Adobe chose to support the Cairngorm framework.

    Yes there are a million ways to skin a cat but they were not there when Adobe started supporting the Cairngorm framework and that’s what people do not realize…


    I disagree. The Flex framework is a component framework primarily. That concepts predates any application framework put on top of it and I would argue that embracing that nature is sometimes the best way to develop an app.


    Coming from Ruby on Rails to Flex, its clear there is a range of ways MVC can be interpreted or implemented. For example, Rails controllers use models to set variables that views use to do their rendering. Cairngorm controllers however modify models that views are bound to, and magically update. I find the Rails approach much more flexible and require less code.

    Rails also manages to keep repeated code and boilerplate code required to satisfy the framework to a minimum. I haven’t been able to bring myself to actually use Cairngorm because of all the code I have to write and files I have to create for even simple operations. Surely this can be consolidated, especially for small operations.

    Also, I have written yet another framework called Cortex, taking ideas from Rails and Mate. Essentially controllers are classes registered with a global Cortex class, then
    CortexEvents are dispatched by the app with controller and action names, and the framework magically routes them to the controller method matching the action to handle the event. It all seems to work well and look neat. I haven’t got around to releasing it yet, but hope to soon. It will be on my blog
    Adopting a framework doesn’t have to be such a big deal or discipline as Cairngorm is.

Leave a Reply