In the world of software engineering, the journey from small-scale solutions to large-scale operations is filled with challenges and valuable lessons. Joel Low, the Principal Software Engineer at Grab’s Developer Experience Team, shared his insights and experiences in this week’s lecture. If you’re looking to join a big tech company or just over-engineer your CS3216 Final Project, catch up on his insights here.
1. Joel’s First Law
“Any system’s structure is a reflection of the communication structure of its creators.” (-Conway)
Joel emphasized that any organization’s communication structure inevitably shapes the design of its systems. In other words, the way teams are organized affects how they work on projects. He says there are two common approaches:
-
One Smart Person in Each Team: You can have one expert in each team who ensures that the team’s work aligns with the organization’s goals.
-
A Team of Smart People for the Entire Organization: Alternatively, you can create a specialized team that sets guidelines and standards for all other teams to follow.
Starting with some level of anarchy and letting teams propose solutions can lead to successful, organization-wide adoption. The “Thoughtworks Tech Radar” model, which classifies technologies as hold, assess, trial, or adopt, can help teams make informed decisions and navigate this process. Joel’s wisdom highlights the importance of effective communication within and among teams, as well as the need for clear guidelines when scaling up engineering efforts.
2. Joel’s Second Law
“As a system scales, its entropy increases.”
As a system grows, maintaining its order and preventing entropy is essential. Joel made an analogy with the second law of thermodynamics: if you want to maintain order, you need to invest energy into the system.
To manage entropy, Joel recommends building platform teams that focus on creating shared components and services. These teams reduce duplication and concentrate resources for the entire organization. Well-designed platforms can make adherence to various requirements easier, from compliance and audits to security and observability.
However, Joel warns that platforms are not a silver bullet; they can’t solve all productivity issues. A balance between investing in platform development and addressing other factors affecting productivity is crucial.
3. Joel’s Third Law
“Legacy code is a result of past decisions made with the best available knowledge and resources.”
Legacy code is often seen as a burden, but Joel encourages respecting it as a decision made in the past with the available knowledge and resources. He cautions against labelling code as legacy just because it’s old, emphasizing that legacy code is only code you can’t change without causing issues.
Joel’s perspective on legacy code underscores the importance of thoughtful, well-documented code for future scalability. He emphasizes that it is worth understanding why things are the way they are.
In conclusion, Joel Low’s three “laws” of engineering for scale provide valuable insights for software engineers and organizations seeking to grow and adapt in the ever-changing world of technology. By considering communication structures, managing entropy, and respecting the past, let’s build systems that thrive as they scale.
