Chaos Driven Development vs. Semper Fi

Sorry for the catchy title, but this is something I’ve often encountered in my career and have repeatedly explained to others—a sure sign that it's worth writing down. Throughout my years in software development, I've seen the entire spectrum of 'flexibility' in team setups. On one end, you have the "Semper Fi" approach, where teams stay together as a unit, working only on their products. If a new project arises, they need to expand the team. On the other end is the "chaos-driven development" approach, where new groups of people form around problems every other week. Looking back, both are anti-patterns, and the ideal situation lies somewhere in between. In the following sections, I'll describe both setups in more detail and highlight their specific pros and cons.

Semper Fidelis

Like the famous motto of the United States Marines, most software development teams tend to stay together and don't consider changing their structure. This approach is perfectly fine at the start of a product cycle. I've often seen how powerful it is to bring a group of smart people together to tackle a specific problem. Especially when the new product isn't fully defined—as is often the case—this setup is ideal. A small group of people who trust each other and have complementary skills can quickly iterate on new ideas for building the product. The problem arises after some time, which could be months or even years, when the product is developed and there’s a need to innovate, typically in addition to established offerings.

Chaos-Driven Development

A few years ago, I was part of an organization developing a mobile app used by millions. We were still at the beginning of our journey, and the possibilities seemed endless. We were deeply committed to agile practices, which I still stand by even a decade later. One of the core principles of agile is to "Iterate Fast"—to build new product increments that are valuable for the user or the organization as quickly as possible. We embraced this principle wholeheartedly and designed a process ensuring that every cycle—in our case, every two weeks—product managers would present the most important topics to work on. Every two weeks, we tackled and built new things. This approach was incredibly fast, and we launched successful new products almost monthly. However, there was no team to address issues that emerged over time, whether they were functional or non-functional. The team that created the code had dissolved, and no one felt responsible for making necessary changes—it immediately became legacy software. Eventually, we had to halt the entire process and revert to stable teams responsible for a set number of services/products. The degrading of quality and lack of responsibility was the reason why we started to call it Chaos Drvice Development.

Conclusion

Even if it seems faster at the start of developing a service to build something from scratch, these masterpieces still degrade over time and require maintenance. You need someone to feel responsible for it—otherwise, it will fail. Stable teams that don't allow new development because they're unable to change their structure usually indicate that the organization can't let go of products/services. If you're able to clear out old projects, you'll also be able to organize teams around new ones. In my opinion, the optimal strategy lies in the middle. The responsibility for critical services needs to be crystal clear, and there should also be the possibility to change the team you're working in if other products take higher priority. What worked well for us was implementing team member rotations between teams. This spreads knowledge across teams and significantly helps member growth. Additionally, clean up your work! There are always services or products that don't provide enough value to justify the effort invested. Identify them and convince everyone that it's much more exciting to start something new!