There is always safety in numbers
In the era of microservices, teams become smaller and smaller.
It is understandable. If you have microservice, you don't need a big team to work on it. But sometimes it becomes too small, and it brings problems.
It is just my vision on this, if you agree or not, please leave your comment.
Why don't I like super small teams?
#no second opinion
don't know like others, but I like when other developers challenge my code or architectural approach. Another opinion on the problem can help to build better solutions and help you to become better.
#software architecture problems
basically, issues are the same as above. Without another pair of eyes, you can build something that only in your mind will look great.
#no real reviews
if you have only 2-3 people in the "team", it becomes tough to do proper code review. Especially if the team is split to FE and BE developers. Most of the time, FE cant check more than fields name, method size in BE code, and visa versa. And some real conceptual issues won't be found.
#project can easily be stopped
If the team is tiny, simple vacation or sickness can stop work on the project. Imagine what will be if the member decides to leave the company. It's a huge risk for the project.
#a bargain with conscience
when you work alone, it becomes easy to skip tests, make a nonoptimal solution, don't cover some corner cases that you know about.
#boring
for me, sometimes it is boring to work in a small team, especially if there is no communication with other teams.
Is there a way to improve this?
__#no less than 5
from my perspective, the minimum team size is five members. Let's consider a simple web application. To develop it, the optimal would be 2 FE dev, 2 BE dev, and team lead in such case we won't have problems related to small teams.
#bigger team working with several services
if you have two small groups working on two small products, make a bigger team that maintains several. In such way, you mitigate risks and avoid problems related to small teams.
#full-stack developers
try to grow or hire a team of full-stack developers. You can cover problems with reviews, with a second opinion. If one of the teams cant work, another developer can build the whole E2E as he can cover both BE and FE parts.
#reviewers from other teams
ask members from other teams to review your code. You will have another view, and understanding that someone else will check your code will keep you in shape.
#big design team, small development team
sometimes the problem can be not on implementation level but the design level. If the team is really small, it hard to have discussions that will help to challenge your architectural decision and identify hidden corner cases that could lead to changes in architecture.
#team mixing
if you are switching members periodically between projects, more and more people will be familiar with them. It will be easier to find a replacement for a person going to leave or for the vacation period.
In the end
The micro team is a risk and can cause problems. Don't forget about it.
If you can improve situation, do it.
P.S.:
- What size of the team do you work in?
- Have you ever worked in teams with less than four members?
- Do you like to work in small teams, or you prefer a big one or several small teams that work on the same product?
- Can a group of 2-3 people be considered as a team?
- Is it reasonable to have such small teams?
Top comments (0)