Software and team structures: the fundamental relationship

Software developers and software architects have, for a very long time, stood on opposite sides of the “whose is better” competition. They have completely different beliefs, with each vowing that theirs is the correct one. Some swear by Java as the holy grail of backend; some worship Go as the right solution to all your backend problems. But, really, is there one right answer? Apart from the tools that you use, the architecture you will be using differs from company to company. Usually, a lot of thought and planning is made when designing the architecture your company will use. Will it be based on microservices? Will it be one monolith? The advantages and disadvantages of each architecture will be carefully considered and your software will be built accordingly. Yet, even with all of this careful planning, what happens when something external affects your decision and you’re not prepared? 

In the software world, this level of unpreparedness can come at a high cost to the velocity and productivity of your devs. Fortunately, at Rookout, we come prepared. Our unique developer tool gives an unparalleled ability to gain understandability into your code, which allows for an easy move between architectures. Unfortunately, when looking at the second part of the equation, there’s no such magical solution for the developers themselves who work with those architectures. While the transition between architectures may be easy, the transition from their regular work environments - like working with a monolith architecture together- to a distributed work environment can take its toll on your team, and we’re not just talking about all those snacks they’ve been eating while working from home. The change to a distributed team from a monolith team can be difficult. With the future unknown, it's important to analyze what this means for team leaders everywhere.

The structural path to productivity

There are a multitude of guidelines and articles comparing the two architectures, some better than others. From my experience working in a software development company, I’ve noticed that one of the most important factors that needs to be considered is how your team is structured and managed. While coffee breaks and happy hours definitely aid company success, ultimately the importance lies in how the company is built. Let’s see some examples:

1. If you have a very small team that works together, communicates with each other properly, and you’re not planning on increasing your team’s size - then perhaps a monolithic approach could be a good choice. It makes sense to let them build something together: the team cooperates well and they know and understand each other’s code. 
2. If your team is distributed, no one really talks to each other and everyone practices different time zones. In this case, you probably should stay away from a monolith as it will probably end up being a modern day Tower of Babel.
3. Is your R&D structured into multiple siloed teams? Every team is the best at one area and you just need minimal interaction between them? Go for building multiple microservices, but make sure that you all agree on the right interface.

In some organizations you can see the opposite happening: the management and architects decide on the software architecture and this changes the team’s structure (or the team’s architecture). However, and this may possibly come as a shock to many, I feel that most of the time your team and its characteristics aren’t as dynamically changeable as your software architecture. 

Force Majeure and your architecture

Sometimes, and usually at the most inopportune moments, unexpected circumstances affect your architecture. These circumstances can be internal or external. As a manager or architect you need to consider them, but also try to not let them cloud your judgement. Some pretty common examples are:

1. Your manager (or sometimes your own team) having read or heard from someone that “microservices is on the list of Top Trends of 2020”. When this happens, the natural response for human nature is for reach for the new and the shiny. I recommend you really try to not succumb to it. While the new and the shiny may look flashy and cool and great for marketing, it isn’t always what is best for your company's success. With that said, sometimes it can be a good solution to test drive and experiment with a small part of your software and understand whether that “trend” is good for you. Experimenting with a small part can satisfy your manager and also won’t demotivate your “trendy” team.
2. You want to make a change, but find that your team has been working with microservices all their lives. Suddenly, talking about a monolith and looking at one seems very scary. As often is the case, making big changes like this can make even the merest of mortals think twice before embarking upon such a journey. There are many ways to transition into changes, though, and not all of them are quite as anxiety-inducing. The process can be quite successful, especially if you do it gradually and educate your team thoroughly. 

So, what happens when you encounter “Force Majeure”? And no, your manager telling you that you “must use microservices because everybody is doing it” is most definitely not “Force Majeure”. “Force Majeure” can be a sudden change to your team due to massive layoffs, for example, or maybe even an M&A that tripled your team. 

Another example is what we’re seeing today with the COVID-19 pandemic. While the pandemic itself obviously doesn’t suddenly change your architecture, the unprecedented circumstances surrounding it are causing the majority of people to suddenly find their team distributed and working from home. If from the get-go your team was tight, small, and very communicative - this has allowed you to have a big ole monolith. Suddenly, the edge you had that enabled your monolith has dissipated.

Maintaining maximum velocity

Software companies, ourselves included, are pretty lucky with the opportunity they have to work remotely. Companies and R&D teams who practice WFH (working from home) regularly, under normal everyday circumstances, are now able to adapt quickly to the current situation, albeit with less of a reason to take as many coffee breaks. Companies whose team’s architecture was distributed and working remotely all the time now find that they don’t really need to adapt and are continuing “business as usual”, such as is seen by ArsTechnica in this interesting article from on how they’ve been doing it for so long. 

If this change doesn’t come naturally to your team, in order to adapt the first thing you have to ask yourself is, “Do I need to adapt?” and then “How is your team’s architecture compared to your software architecture?”.

If in the first place your team has been working on totally different microservices, in which every service was the responsibility of one team member, then anyway you are a distributed team working on a distributed architecture. 

Simply draw a diagram of how connected your team is in order to figure it out. A common team working on a monolith would look like this:

They communicate all the time, work on the same code, might be dependent on each other to deploy, and have a lot of inside jokes.

Break them apart without breaking apart the software and you’ll get what looks like this:

The communication here is more difficult. This team is still working on the same code, but now the overhead of the communication between them will hurt their dev velocity. This team must adapt and compensate for the new situation they find themselves in.

When looking at a team working on microservices, it is as if the change is almost seamless. 

They go from this:

Into this:

Everything was distributed in the first place, and while you might need to make sure your interfaces are tight, you probably won’t notice any major overhead.

If the shoe fits

The main issue here isn’t about which architecture is better. Each has its own pros and cons, but, as we’ve seen, one of them does fit better if you are fully remote and fully distributed. This “Force Majeure” won’t be here forever (all fingers and toes crossed) and I very much hope we won’t see any more occurrences of these situations, so I wouldn’t recommend you start doing anything crazy like fitting your architecture for apocalyptic scenarios. On the other hand, it is important for you to take a step back, look at your team and your architecture, and understand how a sudden change in your team’s day to day work affects your R&D velocity in regards to your own software architecture. 

Focusing on changes and adaptation

When it comes to adapting to your new situation, you have to focus. You can’t do everything all at once in order to cope with current challenges, but rather you must focus on the biggest gaps and address those first. You can’t ignore communication gaps between your team members, even if they are siloed naturally and working on different projects. Because, really, communication IS key. Sometimes, though, it is less important than other gaps which arise due to different factors. Your software architecture is only one of the various factors to take into account. In some companies the biggest challenge may be making sure everyone has a laptop, while in others it can be making sure that everyone has proper remote access to their servers - whether they need full access and start using a VPN or only to debug remotely using Rookout. The factors are many, but ultimately we need to remember that what’s important in these unexpected circumstances is not whose architecture is better, but this: stay safe, stay healthy.