Task Over-Distribution

Published on April 25, 2025

We tend to divide tasks too much and distribute them. I think this affects all fields but I'm going to talk about the tech world because that's what I know. I don't think I'm wrong if I say it's the same in the construction industry.

We over-distribute in two different ways.

The first is by team: the front-end team, the back-end team, the POs & scrum masters, the design team, the architects, the infra & devops team and finally the managers or management. There are rarely all these teams in a company but I think you have at least 5 of these 7 teams in your company.

The second over-distribution concerns the extreme division of tasks. For example, to create a page listing invoices, there will be the front-end part with the development of the table to list invoices and API calls, the back-end part to create the endpoint and download management with permissions, and finally, the infra part for file storage on AWS or other.

If I were to make a connection with construction, for building an extension to our house, we would have: an architect, a mason, a painter, a guy to install drywall and flooring, an electrician, a guy for the framework and a plumber because for the extension we're touching the pipes. 7 different people with different skills to build one additional room. I'm not in the trade, but that seems overkill to me.

Nobody is Responsible for Anything Anymore

Everyone does their little part. It needs to be well done and the rest matters little. This is how we judge the individual's competence. The front-end dev takes care of making their table and API calls to the backend. The back-end dev takes care of creating the APIs to list and download invoices as well as making calls to the file server to retrieve invoices. The infra takes care of setting up the file server and configuring access so the backend can access it and everyone can communicate with each other.

It doesn't work?

• The front-end dev looks at the devtools, no problem detected, the API calls are well made — it must be the backend's fault.
• The back-end dev looks at the server logs, there's no 500 error, nothing abnormal — it must be the infra's fault.
• The infra dev looks at their servers, the dockers are running fine, the files are available, there's no problem either — it must be the fault of poor coordination between front-end and backend.
• What if it wasn't because of the PO? Maybe the specs weren't clear enough.

It's never anyone's fault. Nobody is responsible.

If we detect an error in the devtools, whose fault is it? - Is it the front-end that misconfigured its environment variables? - Is it the front-end that doesn't transmit the right payload? - Is it the front-end that doesn't hit the right endpoint? - Is it the backend that doesn't respond? - Is it the backend that misconfigured its env? - Is it a bug on the backend side? - Doesn't the infra get confused between all the envs? prod, pre-prod, staging, demo, dev, test, etc. - Did the infra properly configure nginx? - Didn't we release a front-end version incompatible with the backend?

Yet everything was coded perfectly. The front-end dev makes a beautiful hexagonal architecture. They wrote tests with Cypress to have "real" tests to verify that everything works. The back-end dev writes unit tests and functional tests to test each endpoint in the smallest corners with the most twisted cases possible. No error is possible! The infra dev has automated everything via super Ansible scripts and all the latest trendy technologies: Terraform, Kubernetes, Helm, etc.

Why despite all this, doesn't it work? Who is responsible? Do we need so many different teams to display a list of invoices and download them?

Nobody Understands Anything Anymore

The application is so complex that each developer is specialized in their domain. They improve their part, but move away from the others — understanding them even less.

• The front-end dev is only responsible for their table and their API call.
• The back-end dev is only responsible for developing their API.
• The infra dev is only responsible for configuring the infrastructure.

Each team ends up with a lot of time to ultimately accomplish only a very small task. So we "apply ourselves". We do things "well" and "properly". We just waste an enormous amount of time.

While some developers doubt the usefulness of tests and even decide to remove them, our teams have a lot of free time. So they implement complex architectures, pipelines in all directions, tests everywhere.

Everything becomes extremely complex, and requires a lot of experience and rigor to be maintained. But the code is clean!

It has become so complex that nobody masters the page to list and download invoices from end to end anymore. Nobody really knows how it works.

It's important to distribute tasks and specialize. Nobody can know how to do everything. And nobody in the world knows how to make a simple pencil! But when it comes to searching in a filing cabinet to find an invoice (or any other equivalent task), I don't think there's a need for so many experts.

What happens if the back-end dev is on vacation and there's a bug in the returned payload format? It's too complex and the front-end dev can't modify it. You need to have rights to the repo, find the place in the code where the payload is built, correct it, modify the tests to account for this bug, create a pull request, have it validated by another competent developer, deploy the modification on a test server, and verify that now everything works correctly.

There are so many processes to follow, so much complexity — nobody understands anything anymore — that a simple correction of this type takes at least half a day instead of the 5 minutes it should take.

It Never Works

Have you ever observed how projects that work are developed? Those famous "legacy" projects. Those that make money for your company, those that allow you to be paid a salary?

We love to criticize these legacy projects. But they all have one thing in common.

There aren't 10,000 developers working on these projects. The dev or devs (it's rarely more than 3) work on the entire part of the project. There's no specialization or distribution by team. Everyone is responsible. There are NEVER unit tests, there aren't ten prod/pre-prod/staging/test environments or others, no SOLID architecture, no TDD, no microservices, no CI and finally no Kubernetes.

We're taught that this is absolutely EVERYTHING YOU SHOULDN'T DO. Yet the project works well enough for customers to spend money to use it. Strange, isn't it?

Of course nothing is perfect, and there are plenty of problems on the project. But that's what pays your salary, not the pipeline with SonarQube.

Conversely, do you know of a successful project with Kubernetes?

Do you know of a microservices project that works? Or a project with functional tests all over the place?

In 10 years of career, I've never seen this work and I don't know anyone for whom it's the case. So of course, there must be the exception to the rule. But that's the exception — not the common case.

The simpler the solution, the more likely it is to work.