Techniques Thoughtworks Technology Radar 24. Satellite workers without “remote native” Hold The term “remote team setup” does not just describe one setup; it encompasses multiple patterns and flavors. And many teams have been changing patterns recently. They’re coming out of the “everybody always remote” mode that was forced on them by a pandemic and moving into a pattern of (often rotating) satellite workers, where part of the team is co-located and part of the team is remote. We see many of them failing to properly consider what this means for their ways of working. Satellite workers without “remote native” ways of working is a slip back into privileging co-located practices. In a setup with satellite workers, it’s important to still use “remote native” processes and approaches by default. For example, if the co-located part of the team joins a meeting together, they should still all be on their individual laptops to participate in digital collaboration or meeting chat. Teams need to be aware of the risk of excluding their satellite workers and creating silos and feelings of exclusion. If you know that you’ll always have at least one satellite team member, the default ways of working should assume remoteness. 25. SPA by default Hold The prevalence of teams choosing a single-page application (SPA) when they need a website continues. We remain concerned that people aren’t properly recognizing SPAs as an architectural style to begin with; instead they’re immediately jumping into framework selection. SPAs incur complexity that simply doesn’t exist with traditional server-based websites: issues such as search engine optimization, browser history management, web analytics and first page load time all need to be addressed. Proper analysis and consideration of the trade-offs is required to determine if that complexity is warranted for business or user experience reasons. Too often teams are skipping that trade-off analysis, blindly accepting the complexity of SPAs by default even when business needs don’t justify it. We still see some developers who aren’t aware of an alternative approach because they’ve spent their entire career in a framework like React. We believe that many websites will benefit from the simplicity of server-side logic, and we’re encouraged by techniques like Hotwire that help close the gap on user experience. 26. Superficial cloud native Hold The term “cloud native” was originally used to describe architectures with characteristics that took maximum advantage of public cloud hosting. Examples include distributed architectures composed of many small, stateless and collaborating processes, and systems with high levels of automation for building, testing and deploying applications. However, we’ve noticed a growing trend toward superficial cloud native designs that simply use a lot of a cloud vendor’s proprietary services and stop there without revisiting the fundamentally monolithic, brittle or toil-intensive nature of the application. It’s important to remember that serverless functions by themselves don’t make an application more resilient or easier to maintain and that cloud native is really a matter of design rather than a set of implementation choices. © Thoughtworks, Inc. All Rights Reserved. 19