It seems more and more over the last year everyone is saying how great frameworks are. There are many types of frameworks and I’m specifically talking about development frameworks as they represent the majority. I’ve listened patiently. I’ve researched various development frameworks (Cairngorm in particular). I’ve questioned their use and I’ve discovered some legitimate use in various circumstances. On the whole they are most popular with managers as they top the buzzword list at the moment right next to ‘Web 2.0′ (despite the fact that coding frameworks are implicitly at the core of any decent pattern based OO Flash development whether you choose to acknowledge them or not). They seem to start as a technical recomendation to solve disperate coding problems and then project managers pick up on them as a general solution, then the managers and then the senior managers and before you know it everyone’s excited about frameworks and how great they are and how they’re going to solve all their problems from now on. And by the time they’re being implemented nobody has asked how or why. Even those who should know better. It’s the Emperor’s new clothes. And the truth is that they are not the solution to all your problems. Don’t get me wrong, I have nothing against frameworks as such, I think they have some very appropriate uses, however, I do have quite a lot against their inappropriate or unneccessary implementation.

A development framework is useful when your workforce is disperately or poorly skilled. Perhaps ‘poorly’ is the wrong word - maybe ‘intermediate and below’ is a better description. It allows you to enforce a certain level of pattern based adherance. It’s also useful when you need to get an external workforce (outsourced, OEM etc) to adhere to your basic development integration standards, so that when they say “it doesn’t work”, you will know with certainty that your framework is tried and tested and if their code adheres to your integration standards requirements then you’ll be able to help debug it more quickly, more easily and with more familiarity than if they’d written it all themselves.

Another classic use should be to help designers plug their work into the application easily and seamlessly. Invariably the best Flash designers are now quite code savvy, meaning they are in an excellent position to take responsibility for much of the ‘V’ in ‘MVC’. However, I have seen designers reduced to jibbering wrecks, questioning their choice of profession when faced with a development framework which was supposed to make their life easier. This is because the very non-bespoke nature of a development framework is not particularly intuative and much of it seems unneccessary and over-engineered (and it is - don’t get me started on over-engineered actionscript - that’s a post for another time). It bears little resemblence to the requirements of the application they are designing for. There’s a whole ‘component framework’ vs ‘development framework’ discussion to be had here of course.

And of course, this is one of the main problems with a development framework. It’s all very well to talk about an enforcing a standard implementation of the MVC pattern, for example, but ’standard’ means ‘less flexible’ and ‘more general’ and ‘larger’ and in environments that have any sort of performance limitations, like mobile phones or Set Top Boxes, that’s just a level of inflexibility and size overhead that an application simply cannot afford. To be honest I’m more of a pureist about it than that even. I don’t personally like to have to implement any formal development framework on any platform as it is never an optimal solution, it’s just an excersise in mediocre coder damage limitation and honestly, that’s just not good enough if you want to produce the best product. You end up with a lot of ‘adequate’ unoptimised applications. Training is a far better solution in the long term, and no better way to learn than to do. The mantra I keep hearing in my head is one of the best practices entries here at Adobe and one I believe in strongly: “Justify every line of code”. Learning OO pattern based design and development and applying ‘best practices’ will avoid much (if not all) of the need and justification for more ridgid development frameworks and lead to powerful, optimised, maintainable, bespoke code. And let’s not kid ourselves, from a purely consultant/contractor perspective the bottom line equasion is simple : better pattern based OO developer = more $/£.

The best solution of course, is to have skilled developers creating good pattern based OO code in a more project bespoke manner and adhering to accepted best practices. Don’t confuse bespoke for arbitrary. This kind of development is more than enough framework for any coder with an understanding of best practices, but with out the bulk of a more formal development framework. On a mobile device or set-top-box, for example, it is potentially an application killer. And even if it doesn’t kill it, business logic says you won’t compete well in the market place if your code is bulkier and slower. Your competitors applications will be leaner and meaner because they built theirs exactly to the product’s functional and environmental requirements and you built yours to a framework because it was easier than getting skilled coders.

So when everyone around you is saying how fantastic a framework is, if they’re wrong, don’t be afraid to say the emperor’s got no clothes.

Permalink