Oh, what a beautiful in-house framework!

Many companies develop multiple software applications simultaneously. Often, the pursuit of efficiency leads them to create an in-house framework.

An excellent idea, one to avoid at all costs. Here’s why.

Putting the cart before the horse

Let’s take the case of an IT services firm developing business applications for its clients. As projects progressed, they realized that a business application is, at its core, always pretty much the same thing: business objects that are listed and viewed in detail to be modified. You could see this as a master/detail pattern, or, more simply, the repetition of a never-ending to-do list. So, nothing too complicated.

Armed with this idea, our IT services firm established its in-house stack: React, Express, and PostgreSQL. It’s true, after all: this makes it easier for a developer to switch from one project to another.

However, that’s where the trouble begins and it’s the last thing we should have done.

The architecture and choice of technologies are guided by business constraints: in one area, there’s a specific requirement for response times; in another, for data confidentiality; and in yet another, for data integrity. This sometimes leads us to complex solutions, yes, but only because they’re necessary.

Conversely, starting with the technology means putting the solution before the problem; it means making things unnecessarily complicated and, ultimately, creating new problems for ourselves. It’s technological solutionism, and it’s the curse of developers. I ❤️ Kubernetes: yeah…

Beyond that, this technological standardization is a form of impoverishment. As a developer, I find myself doing more or less the same thing over and over. It’s just the business context that changes, but hey, who cares about the business… My job becomes a grind, and my mind slowly shuts down as I stare at the hands of the clock 🕜

But it could be worse (as always, rest assured): we could build a custom framework.

Shooting ourselves in the foot

Yes, a nice, rigid framework that struggles to accommodate our requests for changes and puts all projects behind schedule, because there are only two developers working on it day and night, burning themselves out trying to patch the holes. If we have to use a framework, it might as well be an off-the-shelf one, maintained by a large community.

But wait: what exactly is a framework?

A framework is defined by inversion of control: the framework calls my code, as opposed to a library, which my code must explicitly call. So all I have to do is write a little code where needed; I’m not entirely sure how it works, but it works. That’s the whole point, actually, and that’s precisely the danger.

Because, implicitly, the company draws a distinction between those who have to “churn out code” by the mile and those who think. The fundamental problem is therefore indeed a form of Taylorism, which, already detrimental on a production line, makes no sense at all in the world of software. Industrialization has its limits.

So what should we do?

Well, you can do two relatively simple things:

• Across the board, develop components (authentication, application permissions management, design system, etc.) and make them available to all teams;

• Let each team choose its own architecture and technologies, using these building blocks when necessary. In other words, trust them, and get the best results in return.

The finished product will be all the better for it, as will your developers’ sanity 🙏