What happens when companies go from a single small team of developers to tenfold their size as a result of becoming market fit? Could it be that the same patterns that once helped them grow will now halt their progress?
Developer and Agile Consultant Arlo Belshee will teach us about the patterns behind inefficient teams, illegible code, and —of course— bugs, and how to spot these patterns and fix them.
How Arlo started his career
Arlo Belshee started his career as a developer at the end of the 90s. Right from the beginning, he adopted extreme programming. Then a brand-new Agile framework, extreme programming (XP) is meant for delivering software according to dynamic customer requirements. XP encourages teams to prioritize short feedback loops, collaboration, and incorporating practices such as pair programming, Test Driven Development, and code refactoring.
Arlo didn’t waste time in introducing his team to the benefits of XP.
“[We] had the good fortune of being on a team with an experimental physicist; he really drove us to tiny iterations where we tried everything and refined our practice”.
As Arlo mastered XP, he started giving conferences on the subject.
Later on, Arlo started working at Microsoft. Constantly dealing with legacy code, there he incorporated the dos and don’ts of backward compatibility. In his experience, Microsoft held a policy of preserving bugs, since many of them were critical for systems to run properly.
Motivated by these experiences, Arlo claims that most of his efforts in the software industry as a consultant come together to perfect legacy code through eliminating bugs by, on the one hand, learning to read code proficiently, and on the other, writing code free of them.
Developer teams: going from becoming market fit to scaling
As software companies start, their main goal is to become market fit. In other words, they concentrate on developing a product whose target customers are willing to use and recommend.
At this stage, Arlo understands that optimizing their code base and fixing bugs shouldn’t be among team priorities. Their deficient code base won’t necessarily slow them down or at least not critically. Since they’re still looking for market fit, if something doesn’t work or isn’t aligning with what the customer wants, they can take it out completely anyway.
However, once companies find market fit, they need to maintain their product code base to sustain its success, while also expanding it to ensure their product and business keep growing.
According to Arlo, this shift has immediate consequences. He points out that while the product was built by a single team when it found market fit, its maintenance and development are now in the hands of more individuals and teams.
That first team wrote and produced all interactions within that code, but as new teams come to life, the code splits alongside them, and it diverges according to the teams’ different responsibilities, goals, and work cultures.
Consequently, Arlo finds that “code that used to call other code within a team’s responsibility is calling across a team boundary.” In his experience, what happens is that
“The set of habits and norms that made us very successful before that transition are exactly the things that cause problems in that transition”.
Teams only become aware of this issue later on, if ever. Arlo finds two problems that manifest from this situation:
- Illegible code. Often present in code that starts small yet it grows or is split and has jump calls between files.
- Spooky action at a distance. As the teams were divided into new teams, the code did as well, and “what was a local obvious interaction, became a foreign, unexpected, unknown interaction.” As a result, changes in this code made by one team can trouble the work of others.
How to scale in multiple directions at once
Once companies have found market fit, Arlo thinks it is wrong to keep focusing on what has got them there. He refers specifically to the North Star Framework. The North Star Framework has the objective of setting a single and in-common objective for the teams to focus on throughout product strategy.
By providing guidelines fixed on a clear single objective, the North Star relieves teams from decision-making, and consequently, makes them more swift.
Still, Arlo sees that once the company has achieved market fit, the North Star, which was ideal for speeding up development and running experiments, is unfit. In turn, he understands that companies at this stage have to take the opposite action.
Hence, the next step consists of looking at dynamic self-adapting systems
“that are going simultaneously in multiple directions at once and often competing with each other.”
This means that, from this point in time, product development teams must be capable of moving in multiple directions —often opposing— simultaneously.
In Arlo’s experience, the key is to acknowledge that each of these new teams will have its own priorities and challenges. Hence, it is crucial to avoid a top-down approach, given that what a team may need can be radically different from the rest.
“It’s all about empowering the group to identify the problems locally and address them.”
As such, he believes it is critical to decompose those former methodologies and move forward with new ways of working based on distributing decision-making and ownership. To achieve this, Arlo recommends taking three actions:
Become Agile iterative
Prioritize frequent deployments and keep doing demos. Demos or sprint reviews are short meetings about the product in which teams show what they are currently working on to the product owner.
According to Arlo, through demos, teams working on different parts of the product will start looking at product owners as their customers and focus on the specific features they are developing.
Delegate authority
Teach autonomy to teams by progressively leaving them to deal with issues and learn to figure things out by themselves. In Arlo’s own words, “the leader’s job is no longer to ever solve a problem. When asked what they would do, they need to be very clear and say, ‘I expect that you would’ve already implemented the solution. Now let’s talk, let’s look at the gaps and why you weren’t able to, and let’s solve those gaps.’ “
Embrace code refactoring and read by refactoring
In Arlo’s experience, most teams are already familiar and competent with desirable skills such as writing tests, building pipelines, or deploying to the cloud. Still, he also holds in high regard knowing bug for bug compatibility, in other words, to know how to
“change code in a way that I don’t just believe is going to be safe, but in a way that I can guarantee will not accidentally fix a bug that I don’t know exists and maintains full backward compatibility, including behaviors that I don’t know about”.
To achieve this, Arlo suggests learning code refactoring. Code refactoring consists of a series of techniques to improve code by modifying it without changing its functionality. When it comes to ownership, Arlo sees refactoring as a way “to start introducing boundaries between teams”.
How to incorporate the latest technologies into the code base
Arlo affirms that the teams that brought forward the latest technical innovations have already mastered the previous technology, to the point their code bases are proof of it: “The teams that created continuous deployment were all ones that you went and talked to and they didn’t have bugs. When they were talking about testing and production, of course, it wasn’t about correctness. They’d already solved all the correctness issues. They just didn’t have any correctness bugs ever get towards production.”
In turn, when a team with flaws in its code base or lacking specific skills adopts any of these tools, they aren’t as helpful, and can even end up making things worse for its product. Arlo points out this is also the case for microservices:
“they already had really good, high cohesion, well-decoupled code bases, where those code bases were reflected in clean object boundaries, clean method boundaries, small methods, tiny libraries, good relationships between the teams and the codes that they worked on so that most of the code was touched by a very small number of teams. Then what they were doing was bringing ownership to production; ‘let’s take this from being compiled in the library, to being a service that you run and switch the API’.”
Yet, for teams that don’t have this already great code, this level of proficiency isn’t achievable by just moving to microservices. Arlo understands that it is imperative to first acknowledge the flaws teams have to fix them and later adopt new technologies.
The bottom line
Deep Roots is Arlo’s consulting company. Follow the company’s Twitter and Linkedin or subscribe to its newsletter to learn more about Arlo’s work and ideas. You can also visit his personal website or follow his personal Twitter and Linkedin. You can also search on YouTube for the many talks Arlo has given on software development topics.
