However, the question on my mind is not so much when people started using frameworks as a substitute for good design. I am more interested in the why?

In my career as a software developer I've been working with frameworks quite a lot. That is when I came to hypothesise about the incentives that lead to the adoption of frameworks. I also suffered from the often overlooked drawbacks of building upon a framework.

This essay is the first in a series, explaining my thoughts why businesses choose to buy into frameworks in a big way. The next article in this series will explain why I feel some developers cling too much to their frameworks. The final article in this series will contain my advice for evaluating and choosing frameworks. So let's get started!

[Edit] Sandro Mancuso has been pointing out to me that I never defined the term "framework", so here goes: I draw the line between a framework and a library by the flow of control. A framework calls your code (thus limiting your control), whereas with a library, your code is calling the library code. I have no issue with the use of libraries.

Nevertheless, there are frameworks out there that are modularised so you can only use parts of them. They are non-invasive and/or very extendable by nature, e. G. due to a plug-in architecture. Some of the following arguments do not apply to these types of frameworks. I will explain the difference in the third article. [/Edit]

Advantages to the business

Risk mitigation

Software projects still come with lots of risk from a business perspective. And the scariest of all just might be a failed project. No return on investment. We spent millions of dollars on software and we got nothing out of it.

Buying a framework ensures that some core functionality is already working. Why would anyone build his/her own content management system or e-commerce platform or web framework, when you can just get one from an industry-leading vendor and tinker with it? Look, there's a list of Fortune 500 companies on the website of the vendor. If it's good enough for them, it ought to be good enough for anyone.

Depending on the product the decision to buy may be pretty expensive, but the perceived risk is close to zero. And the return on investment is already nigh.

Let's call in the experts

Now we are talking serious risk mitigation: there are successful agencies that do nothing but extend and customise frameworks for customers. Not only do we not need to build this software and risk failure, we also get an expert to blame when something goes wrong with the customisation!

And even if we decide to do the project ourselves, the vendor offers workshops that make any average programmer productive with the framework in no time. If they run into trouble or don't know how to do something we might have to pay someone from the vendor for help. But that's still cheaper than training developers in software design principles and the issues of our business domain.

And we're already half-way done!

Of course most of the core functionality is already part of the framework. So we're already half-way done with the project. All we need to do is take the framework make it look like it's our own. There's just a few cases where the framework does not fit our business. But even in these cases we can try to re-use parts of the framework to speed us up. Sweet!

Overlooked drawbacks

All these arguments appeal to managers. Especially non-technical managers. The over-arching theme is: risk mitigation. What non-technical managers do not see, are the limitations of these frameworks. Especially when they come in the guise of shiny marketing promises. It's the proven, no-risk Lego toolkit to solve all your problems.

Serious limitations

Every framework comes with a certain set of design choices already made. That is what makes developers building on frameworks much faster. There's nothing wrong with that, but it put limitations on the possibilities of any product built upon this framework. Good frameworks come with modularity and allow for developers to swap out parts that do not match their needs.

But some things are not easily changed. When the framework is missing hooks and interfaces to customise or replace parts of the system, it restraints possiblities. I suppose that is where the common saying amongst developers that "Frameworks make 80% of the work easy and 20% impossible" comes from.

This happens for example, when the framework dictates a CRUD based approach for user interaction. This approach forces users are to interact only by creating, reading, editing or deleting things. These approaches are popular, because frameworks may generate most of the code from declarative descriptions of entities. But the one serious drawback of this approach is that user interfaces are bound to reflect the underlying data structures. That is why they do not allow for what the DDD community came to call a "Task-Based UI". A CRUD based UI revolves around data structures. It does not reveal how these data structures inter-relate and certainly not around what the user is trying to accomplish.

We can work around that...

Of course there may be a way to work around these limitations. Hacking the framework, which comes down to misusing it intentionally to get around limitations for example. Hacks have made for the most brittle and cumbersome pieces of code I have seen in practice. Suffice it to say, this is a maintenance nightmare, translating into high long term costs.

What's your competitive advantage?

There is another corollary to the limitations explained in the previous sections. When everyone in the industry is using the same standard software to build upon, gaining a competitive edge is really hard. That is especially true when it comes to businesses making most of their money online or moving online at a rapid pace like the music and news content industry.

What would happen if the iTunes media store or Amazon was just another online shop, hosted on the shoulders of a shop framework? It's unimaginable. These companies build their own ecosystems. They dominate markets with constant innovation. Any attempt to build these services on anyhting but custom software would surely end up with foul compromise or complete failure.

Developing innovative solutions in framework sandboxes can be hard, due to the limitations. If there is no standard way to do something with your framework, you are on your own. And it gets even tougher when you outsource projects to someone else. You will need to work closely with a talented development team to come up with simple and workable solutions. And when you decided to outsource the product development to someone else, you are not in control. You might even get the frustrating answer that it can't be done. Consider the oportunity cost.

All grunt work and no play make Jake a dull boy

As a developer, working with a framework can be pretty dull sometimes. When you are solving the same problems in slight variation over and over again, you are bound to get bored. At least that is I felt working with these frameworks. The most interesting things happen when you break out of the framework sandbox. When you devise hacks that trick the system or just completly decouple yourself and do your own thing.

From a business point of view that's an advantage. All you need to do is hire average developers with high tolerance for repetitive work and send them to a framework class. This is much cheaper for the business. That is because in our industry even a university education rarely involves the teaching of engineering skills necessary to build original systems like the ability to conciously weigh trade-offs. We will talk more about what this means for the software developers that build upon a framework in an upcoming article.

Ok, so what shall we do?

These are just some of the pros and cons you should consider when you or your company is faced with the old "build or buy" question. I prefer to make my decisions based on careful reasoning and valuation of the given options. But even so I think that "buy" is the still the default for a lot of companies. Keep in mind that building upon a framework may limit your ability to innovate.

We will continue with my observations of the framework developer in an upcoming part 2 of this article. I will subsequently post a third article about my process for evaluating frameworks. I will also introduces measures to (at least partially) protect projects from framework lock-in effects. This may give development teams the ability to gracefully recover from bad framework choices.

A little known fact is that Git supports client-side hooks to execute a
command line script before certain commands such as commit or push.
This feature can be used to perform additional quality checks on your
codebase. What's way cool about it is that Git will actually cancel the ...

We are not as rational as we think we are. Or as Dan Ariley might put
it: We're All Predictably Irrational. The other day I read "Die
Kunst des klaren Denkens" (lit: The art of clear thinking) by Swiss
author Rolf Dobelli. One of the common logical fallacies Dobelli ...

A few days ago I started developing my first native Android App. Finally
a green field project! Finally, an opportunity, to do things right!
Finally, a project I could develop in a Test-Driven fashion without the
weight of any legacy cruft slowing me down! Or so I thought...

I recently prepared a presentation entitled "Painless Testing - Writing testable
code" for work and I would like to share it with you. There is a Python
Version of and a Java Version the slides available.

These slides will require an HTML5 capable browser such as any recent
Mozilla Firefox, Google ...

I do apologize for not blogging more the last year or so. This post,
half apology and half promise, marks my comeback to blogging. Read on if
you are interested in what I have been up to and what I plan for the
future.