.png){kind=small}
If we are going for the smallest unit of working software as a goal, shouldn’t we try to develop it with the smallest unit of
Yet, future is coming, either you like or not. It is always better to ride the wave, than to be dragged by it.
Let me start by expressing a stereotyped view of these two types of teams.
Horizontal Teams
1 lead, 15 back-end engineers, 5 monolith services, being the newest close to 3 years old now. The team lead manages all external interactions and specifications with other teams apart from the eventual bug fixing.
Code looks good and many best practices are followed, but it’s hard to merge new code in as there’s always 3 to 4 people working on the same project. It’s hard to refactor core code or to update libraries as this requires everybody to stop for a week.
It’s easy to rotate people around the projects, but each service’s responsibility, its purpose or who consumes it is not clear anymore.
CI/CD Pipelines sure take a while to run and it is quite hard to have them green for an entire week.
Daily stand-ups take 40 mins minimum, and are mostly reporting what was done the previous day. Not all 15 people know everything about the 5 projects and people tend to turn off when the conversation goes about the projects they have little knowledge of.
Even though the output seems to be OK, features are hardly delivered on time since small changes and fixes keep coming after the delivery. It’s difficult to integrate with internal clients.
Vertical Teams
6 engineers (3 Dynamic Duos), back-end and front-end, 2 micro services and 1 front-end micro app.
Everyone is focused on a specific business domain.
Every feature is driven by business and its importance is clear for everyone. Implementation never starts before back-end and front-end agreeing on a
There is a strong sense of ownership from every engineer as they feel responsible for the small software pieces they develop. It’s easy to merge as there is a maximum of 2 persons working in the same source code at the same time.
Pipelines run smoothly and time to release is good as each project is very small and concise.
At all times, there are 2 persons capable of enumerating every business rule for a given project.
The team takes pride on the software produced, feels responsible for it, facing both positive and negative criticism on its own.
Dynamic Duos
Trios work as well.
The premise is to have a low number of engineers responsible for a given project at a given time. If the goal is to develop micro services, why not let it be developed by micro teams?
The idea is to have the tiniest plural unit of software engineering and then let those organise by business domain, rather than by tech stack.
What are the benefits?
Code is more cohesive as there are 2 persons contributing to the base. Every architectural decision takes a small time to be taken as the discussion is held by small number of engineers. Time to production goes through the roof!
Communication is easy — no more 15 people e-mails going around.
It is very easy to understand who is doing what at each moment in time. Supports pair programming.
Small intricacies and business rules are known at all times.
There is a clear contact point, capable of answering every question about the given micro service, be it technical or business wise.
All in all, the development is faster and outpaces that of Larger Teams since the Pregnant Woman Theory is real.
And all this is driven by a GREAT SENSE OF OWNERSHIP.
Yeah sure, but there must be some Requirements
Obviously this way won’t work with everyone nor every organisation.
For this to be fruitful, individuals comprising the duos need to be experienced as well as curious as they will be taking most of the decisions on their own. Each must have great communication skills as they will be upfront responding for their work to stakeholders or clients.
Self-management and drive is also a requisite as there won’t be a Team Lead managing your work.
There must also be a degree of interest on the business side of things as it will surely enhance the final product.
Organisations need to be capable of empowering this small units as well as supporting them with other teams (Architecture, DevOps, Databases etc).
OK, but what if a Dynamic Duo decides to flock out of the company?
There is always the risk that this happens and the fear that this will lead to a loss of critical domain knowledge. But this can still happen with Large Teams and there are ways to mitigate this risk and believe it or not, duos actually enhance this.
One of the options is to increase code coherence and adhesion to best practices. This is easier to be done with a pair of people than with a large folk emotionally disconnected from the object of their work.
And let’s be pragmatic: if there is a large multitude of business rules and logical pathways on a single micro service, you would be doing micro services wrong.
Summing up
1+1=∞
The more the merrier isn’t necessarily true at all times.
As engineers, we are should be constantly trying to break problems down to the smallest addressable issue with the maximum efficiency and minimum entropy. And if time taught us that developing small services with a specific purpose and lean code base has multiple advantages, maybe it’s time we organise ourselves to tackle them the same way.
João Tiago is a Senior Engineer at AddCode.io
AddCode is a newly created company, based in Porto, with fully dedicated teams focused on developing long term projects for our clients.
We offer a multicultural environment, collaborative space combined with knowledge sharing and our remote working policy helps our people to have a healthy balance between work and personal life.At this point, every organisation is going, or has already gone, through the process of leaving large horizontal teams with monolithic software architecture into the fantastic world of agile development with smaller vertical teams and of course: Micro Services.
