Boosting Development Velocity: Adapting Software Architecture to Changing Team Dynamics
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. Yet, the truth is that determining the ultimate answer is far from straightforward. The choice of architecture depends on various factors, including toolsets and company-specific needs. However, even with careful planning, what happens when external factors affect 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 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. The change to a distributed team from a monolith team can be difficult.
That’s why we will explore the concept of development velocity and its intrinsic connection to software architecture in this article. We’ll also delve into the challenges faced by developers when transitioning between different architectural paradigms and examine the critical role of team structure and management in optimizing productivity. So grab that cup of coffee, sit back, and let’s uncover the key considerations for team leaders aiming to boost development velocity amidst changing dynamics.
Optimizing Development Velocity: Where To Begin
Many guidelines and articles compare 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 to consider is how your team is structured and managed. While coffee breaks and happy hours aid company success, ultimately, the importance lies in how the company is built. Transitions between software architectures can pose challenges for developers, affecting their velocity and overall productivity.
Let’s explore the structural path to maximizing productivity and maintaining a cohesive team.
- Small, collaborative teams: 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. Letting them build something together makes sense: the team cooperates well, and they know and understand each other’s code.
- Distributed teams: If your team is distributed, no one really talks to each other, and everyone practices from different time zones. In this case, you should avoid a monolith, as the limited communication will likely cause it to become a modern-day Tower of Babel.
- Siloed R&D teams: Is your R&D structured into multiple siloed teams? Every team is the best in one area, and you just need minimal interaction between them? Go for building multiple microservices, but know that it is crucial to establish a consensus on the appropriate interface to ensure seamless coordination.
In some organizations, you can see the opposite happening: the management and architects decide on the software architecture, which changes the team’s structure (or the team’s architecture). However, and this may 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 Architecture
Unexpected circumstances can affect your architecture, and usually at the most inopportune moments. These circumstances can be internal or external. As a manager or architect, you need to consider them and try not to let them cloud your judgment. Here are some common examples you might find yourself navigating:
- Trendy tech: Your manager (or sometimes your own team) 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 to reach for the new and the shiny. I recommend you try not to 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 won’t demotivate your “trendy” team.
- Transition challenges: 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 significant 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; not all are as anxiety-inducing. The process can be 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 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 saw with the COVID-19 pandemic. While the pandemic itself obviously didn’t suddenly change your architecture, the unprecedented circumstances that surrounded it caused 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 allowed you to have a big ole monolith. Suddenly, the edge you had that enabled your monolith has dissipated.
Maintaining optimal development velocity amidst change
Software companies, ourselves at Rookout included, are lucky with the opportunity they have to work remotely. Companies and R&D teams who practice WFH (working from home) regularly were able to adapt quickly to situations that arose (such as COVID-19), albeit with less of a reason to take as many coffee breaks. Companies whose team’s architecture was distributed and working all the time remotely found that they didn’t actually need to adapt and were continuing “business as usual”.
If this change doesn’t come naturally to your team, in order to adapt, you first have to ask yourself, “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 completely 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 depend 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:
Communication here is more complicated. This team is still working on the same code, but now the communication overhead between them will hurt their development 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 significant overhead.
If the shoe fits
The main issue here isn’t about which architecture is better. Each has its pros and cons, but, as we’ve seen, one of them fits better if you are fully remote and distributed. Whatever “Force Majeure” you’re currently facing – if you are – won’t be around forever. As such, I wouldn’t recommend you start doing anything crazy like fitting your architecture for apocalyptic scenarios. On the other hand, you need 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 regarding your own software architecture.
Focusing on changes and adaptation
When adapting to your new situation, you have to focus. You can’t do everything all at once to cope with current challenges; 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 communication IS key.
Sometimes, though, it is less critical than other gaps arising from different factors. Your software architecture is only one of the various factors to consider. In some companies, the biggest challenge may be making sure everyone has a laptop. In others, it can be ensuring 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: maximum development velocity.
Related posts
