The ability to adapt, collaborate, and continuously improve has become paramount in keeping pace with ever-changing technologies, customer demands, and market trends. In this episode, we discover how Michael Feathers, chief architect of Globant and renowned software expert, addresses the challenges of onboarding teams to complex systems and scaling software development. In his upcoming book, “Patterns of Systems Renewal,” Feathers delves into the process of knowledge acquisition, code comprehension, and system expansion, tackling some outstanding problems faced by the industry.
Edited transcription
Michael Feathers is the chief architect of the software development company Globant and the director of R7K, his own consulting and training company. He is also a member of the advisory board of CodeScene, a tool for code analysis, and the author of Working Effectively with Legacy Code.
Michael’s efforts in software and organization design have led him toward developing new techniques for facilitating onboarding in many different scenarios. Currently, he is focused on helping teams take over codebases they have no experience with or knowledge of, which he regards as an “outstanding problem within the industry.”
Patterns of Systems Renewal
To address codebase takeovers, Michael has developed the concept of patterns of systems renewal, in which he analyzes the process of teams gathering knowledge about the code, understanding it, and later operating with the code and expanding it. His idea is to increase the pace at which this process takes place while also maintaining the understanding of the system, something he believes diminishes over time even though developers keep interacting with the code base.
Michael proposes to achieve this understanding of the codebase by identifying patterns and setting practices, among which responsibility indices are the most prominent. As he puts it, responsibility indices are a mapping practice that looks “at systems not as a set of things, like a set of classes or services, but as a set of responsibilities.” In mapping responsibilities, figuring out where those responsibilities reside in the system is followed by determining “whether it’s a good thing that the responsibility is spread out in a certain way or not.” Mapped responsibilities, Michael believes, can be used to outline goals and find new “ways to interact with the system.”
Patterns of Systems Renewal, Michael’s whitepaper can be found here.
Team Dynamics and Scaling
However, due to their complexity, mapping the responsibilities of larger teams isn’t as straightforward. As Michael points out, Agile methodologies were initially conceived for teams of just six people, and this remains true to this day for different reasons.
First of all, small teams can work and focus in a way that larger teams, embedded in a tangle of dependencies, don’t. On the other hand, small teams have fewer impediments in moving forward with the decisions they take and can react more quickly to the market or other constraints. In turn, larger organizations have more bureaucracy that gets in the way of decision-making and “quite often impacts the engineering organization” resulting often in “cultural constraints that are tough to deal with.”
To acknowledge these issues and understand the dynamic of teamwork, Michael recommends team topology and, specifically, its concept of stream-lined teams to “get back that experience of having a small autonomous team, and having that work well within the context of a larger project.” Stream-aligned teams have a deep understanding of the particular business domain they are working in and the value they need to deliver. As larger products demand a variety of ways to interact with them that are different from each other, stream-aligned teams hold a clear focus on a specific product or service and are empowered to make decisions autonomously within their domain.
In like manner, for scaling successfully, Michael believes large organizations should nurture “larger communities where everybody knows each other [so that] the environment inside that community can basically be much more dynamic.” In such an environment, teams would be flexible enough to be formed and disbanded as necessary and people would have the possibility to opt for teaming up in the ways they see most fit for each project they need to work on.
In all, Michael doesn’t hide his preference for smaller teams; “Scaling is failing,”, he ironizes, as he believes there’s a social notion of giving more importance to things that have more people behind them. More importantly, he affirms that “the amount and quality of the work that can be done by a small team don’t scale with the team.”, arguing that it is the people and their abilities and alignments who deliver results.
Still, Michael does concede that “within the economic and market context that most people work in, you do need to grow in order to go and actually maintain the life of your organization and projects and products.” But even if scaling is necessary, doing so abruptly is stressful. To Michael, making the process smoother comes down to acknowledging that there’s an inevitable period of onboarding with adaptation and learning “and then also generating the structures that are needed to go and have a large group of people work efficiently with each other”. While challenging, this period doesn’t have shortcuts. He recognizes that trying to make it shorter can be detrimental. Hence, the best course of action is “spreading the knowledge” about what the process of scaling and onboarding actually looks like to developers, as well as capitalists, and funding sources.
Modularity and code structure
In addition, according to Michael, scaling also “comes down to how much modularity there is in the system already.” In other words, code and teams should be structured small and fitting within the mental context of developers. To keep this mental context at a human scale, developers should ask themselves if what they are developing is still in the realm of human understanding and at which point would it grow beyond.
As components grow, they have to break into smaller pieces to ensure internal modularity within a larger system. So “when things start to slow down a little bit” it is a symptom of possible changes: tweaking the modularity boundary, the separation of concerns, and the possibility of creating new teams to deal with particular concerns.
In all, Michael advises not to go to the other extreme and “fall into the trap of doing complete functional decomposition,” as it could potentially jeopardize teams’ and components’ independence. To explore and establish practices that nurture independence, Michael recommends Domain-Driven Design “to go and figure out domains that can be active knowledge areas that a group of people know.”
Recognizing and addressing pain
In this way, fractures for modularity will occur organically as teams grow and they notice that processes become painful. Encountering pain, says Michael, should be followed by asking where it comes from and what solutions could be implemented: “Pain is information in software development, and I think that’s an attitude that’s a good one to cultivate.”
Recognizing and addressing this pain starts by spreading awareness of the concept. In this regard, Michael regards the experience of those who have been in that process as invaluable for spreading this awareness and advising teams in the right direction. Experienced people “help convey that mindset and help people see the things to look for.”
Furthermore, Michael also believes experienced people should “recognize when a fresh idea comes along, which might go and make their experience a little bit less consequential.” Even though “hard-won experience is a good thing,” it is not an excuse for being inflexible. Hence, it all comes down to nurturing a “culture where people with experience are networked in a way, the senior people, so that they can actually provide support for each other and figure out how best they can work with people that are new and grow them.” Likewise, the culture will fall apart if you have “too many people that basically are not part of that culture joining at once.” So you shouldn’t grow so fast as to compromise the well-being of the culture.
Durational experience
Michael believes it is only by working with the same product for years that developers will obtain the appropriate experience to fully perpetuate the culture. However, he reflects on how engineers tend to change jobs frequently —a common practice in the industry— and the fact that it is necessary to have in the organization people with ten or five years of experience to perpetuate the culture.
Hence, a developer’s years of experience in their resume might not reflect on their capacity to understand the culture of organizations concerning products’ life cycles. To cultivate the value of durational experience in the industry, Michael invites higher education institutions to make students work on the same project over the years and deliver different things while keeping it so novice developers “get to encounter the consequences of all the decisions you made earlier and then you become aware of your growth, but you also become aware of the consequences of poor decision making.”
Moreover, it is worth noting that the culture could also solidify practices that are not optimal or hold views of things as impossible to apply. In this way, Michael admits that “having a couple of jumps in your career to wildly different areas of experience is good, but also having durational experience.”
Using AI for enhancing development
Michael recognizes that the AI landscape changes at a pace in which today’s brand-new tools could be old news by tomorrow. Having said that, he observes that today AI can but “fill in the details” of what developers are working on and speed up some processes. However, according to Michael, the industry is always demanding the most of its technology. As new AI tools standardize and become a given, they will provide “a small advantage for a short piece of time.”
On the flip side, AI’s tendency to hallucinate —provide information that is plausible yet inaccurate— makes it create things that don’t work. For this reason, QA, reviewing, and testing the code is becoming more important. In this regard, he believes “test first development or test driven development in the context of AI is going to be extremely powerful because it allows us to go and actually create the hard scaffolding to reign in its tendency to hallucinate a bit.” The key is not rushing to eliminate this capacity to hallucinate, since behind its randomness is what makes it creative and valuable.
The bottom line
Follow Michael on Twitter. To learn more about Michael and keep up with industry trends, check Globant’s upcoming events.
As for literature on team topology and Domain-Driven Design, Michael recommends Consultant Nick Tune’s latest book Architecture Modernization, “which is really about the socio-technical realm and how organization and architecture work together.”
