Company Internal Frameworks; Good, Bad, Boring

It is common for software companies to have their own internal frameworks. These frameworks sometimes contain the whole software development life cycle, and sometimes it just boils down to a few tools and utilities.

Consider Temenos TAFJ framework as a case study, this framework has written in Java and can be considered as one of the most complete frameworks in the world it contains all aspect of software development requirements, it has its own data access layer, business layer, etc. plus it provides a special programing language for its developers to develop a new product in such platform.

But some companies do not have a framework as complete as Temenos, they just have for example one calendar utility or more complicated frameworks like form generator. In this article, I try to examine from the perspective of programmers how useful these frameworks can be.

Framework vs. Library

before starting comparison let's have a clear definition and understanding of two words, Framework and library; a library provides a set of helper functions/objects/modules which your application code calls for specific functionality. Libraries typically focus on a narrow scope (e.g., strings, IO, sockets), so their APIs also tend to be smaller and require fewer dependencies. It is just a collection of class definitions. Why do we need them? The reason being very simple i.e. code reuse, use the code which has already been written by other developers.  For example, some library has a method named findLastIndex(char) to find the last index of a particular character in a string. We can straightaway call findLastIndex(charToFind) function of the library and pass the characters whose position we need to find as a parameter in the function call.

Software Frameworks on the other hand is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software.

It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products, and solutions.

The technical difference between a framework and a library lies in a term called inversion of control.

When you use a library, you are in charge of the flow of the application. You are choosing when and where to call the library. When you use a framework, the framework is in charge of the flow. It provides some places for you to plug in your code, but it calls the code you plugged in as needed.

The first major difference between a framework and a library is who is in control of the development process.

With a code library, a developer generally calls upon the library whenever they feel it is appropriate. A framework generally requires that the developer is fully immersed in its workflow.

As a result, it often feels as though the framework is in control of the development process rather than the developer. This is an inversion of control! This is commonly simplified as some variation of the following:

• Library: Call us to get the job done.
• Framework: You don't call us, we'll call you.

Good

Everything is in its place, there are one or more frameworks and libraries, every programmer knows about frameworks architecture or even frameworks codes in detail.

This echo-system gives the developer the feeling of developing with a popular programming language. For example, a programmer has exactly the feeling of coding with Java.

In this case, there is usually a general framework that contains:

1. Companies coding standards like some naming conventions, layers specifications, etc.
2. Governance; provides some facilities like security, auditing for that every programmer does not have to repeat security or auditing related codes and sometimes forgets or does not want to meet these requirements in its own code.
3. Some of well known micro frameworks/libraries in each layer of a program for example hibernate for his ORM, spring-security, etc.
4. Distinctive and separate UI framework; personally I believe that UI and server should not be intertwined, for example, you can choose Java-related frameworks for your server-side but you have JavaScript-related technologies like Angular for your client framework.

Bad 

Actually, there is no framework that everyone accepts; each team has its own framework and library, and organizational teams act like disjointed islands. If changes occur in any part of the system, for example, security mechanisms, all of the teams could take a long time to rewrite the code. In this case, job rotation is very hard because each team has its own policy.

Boring

In this case, everything re-invented from scratch, regardless of existing frameworks, they are sometimes recreated, you have a framework that has its own ORM, MVC, UI Forms, and even sometimes its own programing language. 

This framework increases the speed of production and you can deliver features in a short time with lower-level programmers or even with domain experts, but it’s boring for customers and programmers for two reasons:

1. Most of the time, you have a fixed and boring product theme for customers and in the long run, it bores the customer, and may not be meet the new customer requirements. Any new requirements must be changed according to the power of this framework to be able to do.
2. Programmers should develop the requirement only in the scope of the framework and they cannot do anything outside the framework. Many times they ask themselves this question; am I not a programmer, for example, Java? This will cause the developers to get bored and leave the company in the long run.