The trouble with custom frameworks

If there is one thing I hate, it's poorly designed custom frameworks!

Why is it that so many companies invent their own frameworks anyway? I have a few theories: (1) Frameworks are more fun for developers to write than application code (2) Managers have been oversold on the idea that you write a framework and somehow it saves a lot of money (3) People grossly underestimate the long-term impact, cost and lock-in a "framework" imposes upon a company (4) Most developers overestimate their abilities as a framework designer.

Real-world case study - A business object framework

This story is about a company that created their own "business object" framework.

Many companies like to create business logic frameworks to enforce a methodology for constructing business logic. This seems like a reasonable approach; encapsulate underlying infrastructure 3^rd party frameworks, provide a layer of abstraction “framework” so everyone writes business logic the same way as well as providing additional services which normally burden business logic developers.

This company had a history of mixing business logic and user interface logic, which made applications very difficult to maintain. The CTO and developers sold the management team on a solution for this problem, and you guessed it, the solution was a framework. However, this turned out to cause far more problems than it ever solved.

Although the intentions were good, things didn't turn out well. Why?

• Adding more complexity instead of making things simpler – Most home grown frameworks of this ilk start off with the lofty goal of simplifying business logic development; and initially with a minimum feature set it appears to work. However, it is very rare that in the course of implementing all the real-life necessary features that are ultimately required that the home grown framework is in reality simpler than not using the framework at all. Without a framework middle-man in the way, developers have easy access to third party frameworks such as Spring, Hibernate, etc. When a home grown framework encapsulates everything, the developer no longer is working with well documented and main-stream understood 3^rd party frameworks – he is working with something else entirely different. Moreover, when bugs or problems occur the business logic developer winds up diving into the framework's source code to fix the problem. The net effect is that the job for the developer is now more complex: He has to know and understand the underlying infrastructure of 3^rd party frameworks plus the home grown business logic framework that lies on top of it.
• Preventing development improvements – As with many home grown frameworks, this one was foisted upon development projects. Management simply spent too much money creating it to not insist upon its usage. Developers were told they must use it in the name of consistency for the company. However, when the home grown framework doesn’t have all the features needed for a project or is awkward and difficult to use, the entire development organization is held hostage to the framework’s problems and limitations. In this case, the management push for the framework squelched any dissension and negative feedback, further creating problems.
• Feature lock-in – Since business logic developers were required to use the home grown framework, it became a bottle neck. All applications and services were affected by it. Every application was limited by the home grown framework’s limitations and complexities. For example, if a specific feature was needed and the home grown framework did’t provide it, every application in the company was affected.
• High Cost – A development team needs to design, code, document, bug fix, test and enhance a business logic framework. Unless your company is in the framework selling business, building frameworks is a pure overhead expense. Often the real costs of framework development, maintenance and documentation are glossed over by the developers selling it in the company. This company was no exception.
• Inadequate staffing – When building your own framework, you need to have dedicated resources to work on it. These resources need to be available not just at its inception, but continuously over the lifetime of the framework. Most companies are in business to provide applications and services – not sell software frameworks. As a result, it is rare that companies have enough staff to adequately maintain a business logic framework. Frameworks require significant on-going efforts. For example, virtually every popular open source framework undergoes a major re-design every few years. In this case, developers sold management that the framework was a "quick and easy" solution, which it was for its initial incarnation but neglected to account for the long-term maintenance and enhancement such a beast requires.
• Underestimated complexity – Most home grown frameworks start off with basic features. Over time, people discover they need more and more features in order to get their work done with it. Technology changes too. What was once a “simple” business logic framework mushroomed into a big framework with lots of classes. Most organizations underestimate the scope of such a framework. This company was no exception.
• Framework Design is difficult – With open source frameworks, the entire development community determines the popularity of a framework. If it is highly useful, it will become popular and more resources will join the project. If it is not or if there are better options – the framework withers on the vine. Designing and implementing a good framework is very difficult - more difficult than it seems. Only very few open source frameworks ever succeed because of this very reason. Before embarking on such a project, a developer should ask, "Is this good enough to be the next Spring or Hibernate and do I have skill and resources to maintain this at that level of quality?".
  

Bottom-line is this company’s home grown business logic framework hurt the company far more than it helped the development of business logic.

Once a framework gets used, it is viral in nature becoming embedded in business logic or application code and is typically very difficult to remove later. Like most companies, they didn’t have time and resources for a major refactoring event to remove the home grown framework that was’t working or allow a major redesign of the framework to fix problems. Also, the CTO and management team had great difficulty admitting such failure occured on their watch. Instead, the home grown framework has to be continually enhanced because in management's short-term view, it is cheaper to live with a problem framework than it is to admit failure and remove it.

There was a better way.

By learning enterprise design patterns and doing good research into 3rd party frameworks, this company could've got all the benefits the home grown framework was supposed to provide without any of the cost overhead and limitations it imposed.

In this case with enterprise design patterns, one can enjoy the following benefits:

• Standardized development methodology for business logic development
• Layered architecture on purpose
• Clean separation of concerns
• High degree of maintainability for business logic code
• Simple, well-documented use of 3^rd party software that everyone can understand
• No “middle man” software framework to forcibly restrict developers from using the features of the underlying 3^rd party frameworks.
• Ability to easily incorporate the latest features and enhancements as they are added to the underlying 3^rd party frameworks