Hail To The Framework: The Framework Fever Of Software Companies...

This post is about project-based software companies. They deliver tailor-made software solutions to their clients on a project basis. There are a lot of them in Belgium… and when I say a lot, I really mean a lot!

During my many contacts with these companies I have been increasingly confronted with this phenomenon that I can best describe as “Framework Fever”. For some reason these companies always seem to end up in a situation where they decide to start developing a generic framework that can be used to configure and customize end user solutions.

“Framework Fever” can strike at any time and for many reasons: a desire to speed up the development process; a desire to offer a more standardized product or a desire to increase the productivity of employees.

Companies affected by “Framework Fever” are usually blinded by it. They are obsessed by the advantages but fail to assess the risks sufficiently. In my opinion this is because the introduction of a generic framework is often considered as a technological challenge alone. Many of the failures I have seen can be traced back to situations where

  • the organizational aspects have not been covered correctly; or
  • the company was not anticipating the right variation points.

Let me elaborate on these two.

Making a framework requires a different organization. In a project organization, people move from one project to the other. A generic framework however survives projects and requires therefore a more stable team to work on it. This might conflict with the project activities. The framework of SEI gives more insights in this topic.

Making a generic framework implies anticipating the variation points. One has to understand upfront the commonalities and variations of future customer requests. In many markets and domains this proves to be extremely difficult. In my opinion many software companies fail to install a manageable process for reasoning about variation points. Deciding about which variation points to support —if done at all— is done by team members who do not have the appropriate business knowledge to do this. At several occasions I have seen “Framework Fever” resulting in an overly complex and generic framework that opposes the original goals: it makes development slower or it requires a huge learning curve.

The point I want to make in this post is not that you should not consider frameworks, but if you do, you should understand also the non technical implications. This is an exciting domain that is being explored in the VariBru project. Contact us or join the regular VariBru gatherings if you want to know more about it.