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.
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:
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.
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:
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.
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.
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.
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.