Rapid team growth in a single codebase leads to development friction, increased complexity, and slower delivery times.
As a monolith grows, development slows down due to the need for extensive communication and alignment across many teams.
Assigning strict code ownership creates walled gardens, knowledge silos, and dependencies that hinder collaboration and slow down development.
According to Conway's Law, your organization's communication patterns will ultimately determine your software architecture, making cultural change a prerequisite for technical change.
Move from a mindset of protective ownership to one of collective maintenance by allowing people to go to the work and adopting an inner-sourcing model.
Choose meaningful, visible projects that can be completed within a few sprints to ensure they are large enough to matter but small enough to manage risk.
Treat improvements as experiments by forming a clear hypothesis, testing it, analyzing the resulting data, and iterating based on what you learn.
Ensure success by making small, iterative changes, prioritizing easy rollbacks, and investing in documentation and code quality to support future work.
Instead of debating monoliths versus microservices, focus on decoupling code and improving team collaboration to build a more modular and maintainable system.
The discussion covers managing documentation through the definition of done, the ideal team size of four to six engineers, and using a buddy system for onboarding.
Hubert Burda Media
München, Germany
42:02Simon Lasselsberger
43:13Carola Lilienthal
46:24David Leitner
27:32Michael Eisenbart
58:23Luka Samaržija & Ivan Sokol
43:20Josh Goldberg
25:05Eberhard Wolff
34:36Werner Vogels
.gif?w=240&auto=compress,format)
Jobs that call for the skills explored in this talk.
Event-driven Architecture
Event-driven Architecture
Resolution Technologies, Inc.
