I focus on helping teams and organizations reduce technical debt. This means a lot of work in legacy applications. But once technical debt has been reduced, it’s important to think about how we will avoid creating too much new technical debt in the future. Of course, there will always be technical debt, but we should try keeping it to a minimum. Today, I would like to write about company frameworks and how they often increase technical debt, while providing little value.

The Incentive

Many organizations have a management layer that has a limited amount of technical knowledge. This shouldn’t be a problem, as there are also other domains where management has only a bird’s-eye view of (legal is one that comes to mind). A lack of such knowledge shouldn’t stop them from being good managers. Indeed, it’s the reason why they (should) hire skilled people for certain tasks. On the other hand, there are developers with technical knowledge, but often less knowledge of (and access to) the business side of things: costs, budgets, strategies, etc.

After a period of time, management will notice and identify the “smart” developers. These are often experienced developers with a proven track-record, though this isn’t necessarily the case. Office politics can come into play here as well. Whatever their capabilities, it can occur that management assigns to them a leading role, that spans over multiple teams. The responsibilities can vary between companies, but often include things like:

• drawing out the company’s technical architecture
• keeping an eye on code quality
• helping teams implement certain coding standards
• developing components that multiple teams will use

This last piece is where management hopes to reduce costs. By sharing components and building on a shared base, teams can develop and achieve results faster. And faster development means costs are reduced. So management has a rational incentive to set up a team that will develop shared components.

The Birth of the Company Framework

It’s very likely that all teams will need to connect to a database, connect to the message bus, write logs, share a common look and feel, make HTTP requests, etc. So one or more developers come together to write this code that will be shared by all teams. This is often where it starts to go wrong.

As different teams needs more and more common functionalities, the set of libraries grows and grows. At this stage, it’s very likely that the libraries become dependent on each other. Thus, a framework emerges. It’s no longer a set of libraries where teams can pick and choose what they need. Now, it’s a full-fledged company framework that needs to be used in its entirety.

Another dynamic at play here is a lack of trust in developer’s skills and ability to learn. I’ve often seen company frameworks hide away slightly complex pieces of code that are part of the programming language (.NET Framework, NodeJS, Python, etc). Instead of educating the teams on how to use the programming language, they assume the other teams won’t be able to handle the complexity. So they add some utility classes and methods to the company framework and let the developers use those.

Assuming the other developers don’t have the necessary technical skills to write a decent application not only shows a lack of respect and trust. It also hinders the other developer’s chances to learn and grow, which makes the whole thing a self-fulfilling prophecy. In the end, the organisation risks being left with unskilled developers. While that may be nice for the ego of the company framework developers, it’s bad for the organization.

One final aspect that leads to the creation of a company framework is fun and ego. Some developers seem to like spending company time and money on something that only serves to satisfy their own needs. They enjoy working on a piece of code whose use is mandated, i.e. used by many, loved by few.

Why Is A Company Framework Considered Technical Debt?

So your company has a company framework. Why is that so bad?

As mentioned above, it leads to your developers learning the company framework instead of the programming language they use, e.g. they learn the ACME Framework instead of the .NET Framework. Why is that bad? Because they will start falling behind on the evolution of the programming language and write more and more bad code. The technical debt they produce will increase over time, even though (or sometimes because of) they use the company framework.

Can we then combine great developers with a company framework? Only if the company framework doesn’t get in their way of producing good results at a decent pace. Good developers want to use good tools, and probably in their own way. Company frameworks often force them to work in a certain way, which they might not agree with. When these developers think about their future in the company, this is one extra tick in the “leave”-column.

The two previous points are summarized in the great story about the CFO that asks the CEO: “What if we invest in developing our people and they leave?” The CEO answers: “What if we don’t, and they stay?” A modern organization must assume that people will leave eventually anyway. What you don’t want is that only the “bad” people stay.

Besides keeping unskilled developers unskilled, and driving out the skilled developers, there is a third reason why company frameworks lead to technical debt: existing libraries are often better and more up-to-date. Most of the common concerns that teams need addressed, are already solved by existing libraries. If you need a certain functionality, it’s always a good idea to look around on the internet. Maybe some group of people have already solved your problem. This allows you to focus on your core business problem, which is specific to your company. Logging, database access, HTTP calls and UI controls are all things that are probably not specific to your problem. Use existing solutions and realize that those aspects of your project aren’t special.

Finally, these existing libraries likely have a larger community than the company framework. Many of such libraries are open-source and have several active contributors. For example, NLog has 128 contributors. They also have many more users. To take NLog as example again, the NLog Nuget package has more than 13 million downloads. While these numbers don’t tell us exactly how many active contributors and users there are at this moment, they do tell us one things: it is safe to assume that an issue in the library will be noticed and fixed before you realize it.

All of the above leads me to conclude that company frameworks are a large source of technical debt that a company should not have.

Getting Rid of the Company Framework

What do you do if you already have a company framework and want to phase it out? The answer here will be “it depends.” It depends on the structure of the company framework. But there are two strategies that can work:

• Pull the company framework apart into separate isolated components, that you can replace by other libraries later
• Replace the company framework piece by piece in the different applications, until nobody uses the company framework anymore
• Stop using the company framework in new applications, optionally migrating to microservices

In the first option, the maintainers of the company framework would need to do a lot of groundwork before the different teams can start replacing the company framework. The idea here is to change the company framework so that it is no longer a tangled mess of libraries that depend on each other. Instead, you should end up with separate libraries with as little external dependencies as possible.

This option seems quite costly because it means both the company framework team and the application teams need to do some work. However, it might be necessary when certain pieces can’t be replaced with an external library. Also, the application teams can do this work while the company framework team is still pulling the framework apart. For example, if the logging is already a separate library, but the UI, database and messaging pieces are still lumped together, the application team can already start replacing the logging pieces in their code.

A second strategy could be to leave the company framework as it is, and just have the application teams start replacing calls to the company framework with calls to another library. This is definitely more interesting as it doesn’t require any work on the company framework. But it might not be a realistic option for everyone, if too many pieces of the company framework depend on each other.

In both cases, the applications will probably still need to pull in the entire company framework. They only use less and less of it, as time goes by. In the end, the team will find they don’t use the company framework anymore.

A final strategy could be to keep the company framework in the existing applications, but no longer use it in new applications. Older applications might go into a “maintenance mode” and no longer need a lot of attention. If they do still need attention, this strategy could be combined with replacing pieces of existing applications with microservices, which don’t use the company framework.

A Final Word on Frameworks Versus Libraries

The company framework I’ve written about here, is the set of libraries that tries to cover all grounds and where the libraries all depend on each other too much. It makes it practically impossible to just use one functionality.

This is not to say that every application team should solve the same problems. But when common solutions arise, it’s better not to incorporate this into a company framework. Keep the common functionality in a separate library that teams can choose to use, or not to use.

And while we’re thinking about this, who says such common libraries should be developed by a special team? Why not have your most skilled developers just work inside teams, educating others, and let teams share there libraries with each other?

It seems most organizations no longer start with a company framework, but many mature companies still have one (or more!) in use. The above should give developers and managers enough arguments on why it should be phased out and how to do this. If you’re interested in getting help for your specific situation, I can help out. Don’t hesitate to get in touch. My help could range from general advice to actually helping implement a solution.