Our software projects often involve the same questions from our customers. Do we really need a framework ? Shouldn't we develop all this ourselves? Do we need to be dependent on external libraries? The answers, in a nutshell: Yes. No. And: That depends. More on that later.

What are the fears?

But where does this scepticism about libraries, frameworks and external dependencies come from? Often it stems from fear of dependency and a loss of control. These reasons should of course be taken seriously in product development. What happens when a framework develops in a different direction than your product? When the development of a library is stopped? Or when a security vulnerability arises?

Why are there frameworks and software libraries?

Let's look at it from a different perspective. Why are there frameworks and software libraries? For a similar reason, there are screws, saws and wooden slats in the hardware store: You don't want to cut down trees yourself to build a fence.

With prefabricated parts, software libraries, we don't have to reinvent the wheel. Instead, ready-made components help us reach our goal faster, safer and more efficiently.

Well then, what are the problems with external dependencies?

Problems arise when

• the matching wooden slats for the second half of the garden fence are no longer available,
• the purchased screwdriver no longer fits the new screws
• or the saw has an increased risk of injury due to a production failure and is called back.

But is the knowledge of these potential problems enough to cut down the trees yourself and make suitable wooden slats out of them and to enter into screw and saw production yourself? Probably not. Also: How likely are these problems anyway?

Are these problems really likely?

Let's stick to the garden fence scenario: As long as the sales of wooden slats are suitable, the manufacturing company will keep producing them. It is possible for the product to be phased out, but there will usually be stocks of them or a transition period.

The screw company will be interested in maintaining compatibility with existing tools. Even with a new screw version, the old ones will continue to be produced for some time. At least until enough people have switched to the new system.

And in the case of the saw, we can assume that there will be a call-back in the event of a production error. The faultless saw will almost certainly be replaced free of charge.

Why not develop everything yourself?

This also happens with software libraries. So why not do everything yourself? Then you don't have these problems anymore, do you? That's true, but you have a whole different set of problems.

If I want to build a garden fence on my own, I have to cut down a tree myself. Then I have to process it for matching wooden slats. These are many steps that I am not familiar with. I know more about fences than I do about preparing trees. Efficiency, quality and cost suffer as a result of my lack of know-how and equipment.

The strategy "Do it yourself" - or "re-invent the wheel" - is not competitive. I do the same thing as specialist companies. Only more expensive and worse.

What’s to consider when dealing with external dependencies?

Doing everything yourself isn't the answer. But how do you avoid the real risks of external frameworks and libraries? How do you find the ones that won't cause any problems? We have defined a few points that will help:

Distribution

How many other projects use my external component? Frequently used screws are likely to continue to be produced and compatibility is more likely to be considered for further development. This is less likely for an exotic screw variant.

Background

Who developed the saw? A single person or a large company? Is the saw a main product or just a sideproject? Is the production of the saw protected by a patent or is it a trade secret or are the plans freely available, i.e. "Open Source"?

History

How long have these wooden slats been around? Are they proven or do the first teething troubles still have to be discovered? How did product care and troubleshooting work so far? How quickly are reported defects responded to? How many open bugs and problems are there?

Functionality

If the slats are only available in three lengths in the DIY store and I need something in between, then I need custom-made ones. Frameworks and libraries also have to fit the application. With inappropriate frameworks you have to program a lot "around the outside" until it fits. Raise the foundation of the garden fence because there aren't any longer wooden slats. Sometimes this "rebuilding" is more complex and error-prone than a replacement, or even an in-house development.

These questions help with a choice. The final decision, however, always depends on your own requirements. A software system in banking has different decision criteria than Netflix when it comes to external libraries.

Is it always wrong to develop something yourself?

If there are suitable and established solutions, they should be used. Of course there are exceptions for this rule, but they are rare. You save time, money and can concentrate on solving your own core problem. Maybe there is no library for that yet.

If there are external dependencies, the exchangeability of libraries can be taken into account and facilitated in advance by an anticipatory system and software architecture. There are suitable architecture patterns for every software system. From facade design patterns to micro services and micro frontends.

Individual development is the right decision if it is done for a good reason. For example, if existing libraries only solve a problem insufficiently or if they do not meet your own requirements in terms of security or performance.

Conclusion

No fear of external dependencies! Defined criteria and guidelines help in the selection of external dependencies. The same applies to reports by others who already have experience with it and can point out advantages and pitfalls. The selection of external dependencies and suitable architecture is the foundation for an efficiently maintainable, powerful and secure software system. Regardless if it's a website, web app, mobile app or server system.

Need help with finding the right framework or library?

Get in touch