I have built many frameworks over the years and I have a love-hate relationship with them. Building frameworks or other types of abstractions such as code generators, template engines and so forth are great creative outlets which tend to distract the over-burdened developer from the primary task at hand which is shipping software. They’re a lot of fun to think about and build and you don’t need to worry about those pesky business requirements. But are they worth the investment?

The first problem with a framework is the requirements. Since frameworks tend to be non-functional in nature they are difficult for a business analyst to nail down and typically they need to be spec’d out by someone who understand the technology.

This is the honeymoon period, when the idea has no form. Everyone loves the idea of a framework. Once code starts being written however, that’s when the cracks start to appear.

There is a trick to building application frameworks. The trick is knowing when to stop. You have to have a very clear delineation of where the framework stops and where the application developer’s job starts. Too much on one side and the framework adds little value, too much on the other and it tries to be all things to all people. Neither is good.

Jeff Atwood claims that all abstractions are failed abstractions, meaning at some point you run into a problem where the abstraction generates worse results (code) than if you were to implement using the underlying layer itself. The example he gives is with LINQ and SQL. This is not uncommon and I’ve also seen this with Hibernate and SQL. You can very easily generate the worst explain plan in history with a naive developer who’s new to hibernate.

Abstractions are typically born out of a need to do more with less (classic problem of engineering). How to churn out more business functionality with less effort, money and or skill? This leads to a useful metric which is when the actual effort spent to use your abstraction layer equals or exceeds what it would take were you to use the underlying technology itself then you’re better off just coding it without the framework.

The corollary to this is when the Framework takes more effort to code than the sum of the effort it will save. When you can take 1 smart developer for a week and have him write something that’ll save 10 developers 1 week each, then you have a good case to build a framework.

Conversely if it’s going to take more effort to code something than the effort you’ll save the efficiency-gain argument is lost. You might still have a chance but you need to make a different argument e.g if the framework will somehow ease the maintenance or performance or governance burden of the code overall then perhaps you can still make the case for an abstraction.

It’s almost always better to avoid writing code if you can. The second you write code and roll it out, you are now on the hook to maintain that code.

Another thing developers LOVE to do is to write “wrappers”. I hate wrappers. Just one extra step between me and chocolate. I think people like wrappers because they sound benign enough (it’s just a “thin wrapper”) and yet they allow the framework developer take all the credit for the underlying component, as if they’d written that themselves. If you write a framework that’s built on a product you are typically tied to the product upgrade path, a burden not to be taken lightly, even if it’s a “thin wrapper”.

Regarding Extensibility; you can never anticipate the depth of developer’s creativity. That’s a nice way of saying you’ll never figure out all the kludgy ways developers will try to use your framework. The only option is to leave room for extensibility. Live and let live. Developers hate to be backed into a corner and if your framework is to be adopted it must allow many other flowers to bloom.

Lastly, I have only ever seen a framework work when it has been steered by one person with an end to end vision. Design by committee does not work. Peer review is fine but ultimately you need a Benevolent Dictator who must steer the ship and determine if the framework is to succeed or fail. If a shared vision can be achieved this is ideal, with multiple people all following the same path. But this is rarely achievable. It’s sort of like asking Picasso to have Rembrandt and Warhol finish his painting.

If we can leave Frameworks for a minute, Code Generators are another type of abstraction (or destraction) and yes code gen is cool. I can still remember the first time I got Lex and Yacc to draw a circle on the screen or the first time I reflected a class. Fun. But in the end you need a code generator that’s smart enough to handle all your corner cases in order to justify its existence. Code generation is useful for quick-win type situations but if you go beyond basic CRUD operations and screens it becomes very difficult to build the intelligence into the generator.

Frameworks, Code Generation and Abstractions tend to attract architects. This is generally not a bad thing but beware what Joel Spolsky refers to as “architect astronauts” [LINK]. If you get into the business of developing frameworks you’re going to run into these people. They’re like moths drawn into the cold-neon glow of the framework. They get close but never close enough to contribute in real terms. Mostly they just make noise as they rap against the window.

In summary, I’m pro-framework and pro-code generation but only to the point where it holistically makes sense. Here’s the formula I use:

if (effort to build the abstraction) + (effort to train developers) + (effort to maintain abstraction) < (effort saved by using the abstraction)
AND
You can design the abstraction to be extensible
AND
You can’t find something on the market that’s already covering this space
THEN…
go ahead and build it.