Techniques Thoughtworks Technology Radar very long time or be very challenging to achieve. With tactical forking a team can create a new fork of the codebase and use that to address and extract one particular concern or area while deleting the unnecessary code. Use of this technique would likely be just one part of a longer-term plan for the overall monolith. 10. Team cognitive load Trial A system’s architecture mimics an organizational structure and its communication. It’s not big news that we should be intentional about how teams interact — see, for instance, the Inverse Conway Maneuver. Team interaction is one of the variables for how fast and how easily teams can deliver value to their customers. We were happy to find a way to measure these interactions; we used the Team Topologies author’s assessment which gives you an understanding of how easy or difficult the teams find it to build, test and maintain their services. By measuring team cognitive load, we could better advise our clients on how to change their teams’ structure and evolve their interactions. 11. Transitional architecture Trial A transitional architecture is a useful practice used when replacing legacy systems. Much like scaffolding might be built, reconfigured and finally removed during construction or renovation of a building, you often need interim architectural steps during legacy displacement. Transitional architectures will be removed or replaced later on, but they’re not just throwaway work given the important role they play in reducing risk and allowing a difficult problem to be broken into smaller steps. Thus they help with avoiding the trap of defaulting to a “big bang” legacy replacement approach, because you cannot make smaller interim steps line up with a final architectural vision. Care is needed to make sure the architectural “scaffolding” is eventually removed, lest it just become technical debt later on. 12. CUPID Assess How do you approach writing good code? How do you judge if you’ve written good code? As software developers, we’re always looking for catchy rules, principles and patterns that we can use to share a language and values with each other when it comes to writing simple, easy-to-change code. Daniel Terhorst-North has recently made a new attempt at creating such a checklist for good code. He argues that instead of sticking to a set of rules like SOLID, using a set of properties to aim for is more generally applicable. He came up with what he calls the CUPID properties to describe what we should strive for to achieve “joyful” code: Code should be composable, follow the Unix philosophy and be predictable, idiomatic and domain based. 13. Inclusive design Assess We recommend organizations assess inclusive design as a way of making sure accessibility is treated as a first-class requirement. All too often requirements around accessibility and inclusivity are ignored until just before, if not just after, the release of software. The cheapest and simplest way to accommodate these requirements, while also providing early feedback to teams, is to incorporate © Thoughtworks, Inc. All Rights Reserved. 15