Large Teams and Object Oriented Programming

Principles are an important thing. However, like any other situation where principles are important, the principles of object oriented programming occasionally require a little extra thought to implement when things get difficult. In particular, as your team grows, a lot of the things that you learn early on in OOP have to be adjusted to the reality of working in a larger team. While this isn’t exactly a compromise of the principles of OOP, it is definitely a learning experience that will deepen your understanding of proper practices, usually after it frustrates the crap out of you. Like an object model with many different types, the interactions of a large team become more complex in a thoroughly non-linear fashion. Eventually, this complexity will require you to adjust the way you interact with the system, lest the whole thing come grinding to a halt. If you don’t, the resulting stability issues will make it hard to get anything done. For interpersonal interactions, most organizations will divide responsibility among a set of smaller teams to limit the number of challenging interactions. In an OOP codebase, a similar approach is applied, but you’ll find that it doesn’t tend to always work the way you might expect. Managing large teams of people who are working on the same codebase can often result into some interesting problems within the codebase. OOP can be a useful paradigm when building an application. However, the principles of OOP as taught in a textbook are not necessarily the way things get implemented in messy, real world scenarios. As your team grows, team dynamics and interactions tend to force some changes in how code is written, designed, tested, and managed. While textbooks will teach you general principles in a fairly clear cut manner, the application of those principles in the real world, especially on a larger team, might not be so clear cut. Episode Breakdown The basic reasons for team and codebase growth. It goes without saying that the reason you tend to see large teams working on large codebases is because there is an economic value in doing so. It’s unlikely that a large team will remain employed very long if that’s not the case. Further, given this economic value, larger teams and codebases have to be able to prove their value regularly, or they are at risk of being cut. This means that deliverables must be met and systems must remain stable. This tends to place schedule and feature set pressure on the team. Complex systems tend to evolve from simple systems over time. This additional complexity is often required to deal with hidden complexity in the real world systems that the code is supposed to address. This added complexity tends to require more and more people to deal with it over time. YAGNI is often provably false. YAGNI means “You ain’t gonna need it”. In general, it’s a good rule and suggests that you shouldn’t gold plate your code for future scenarios that you can envision, but which have not yet come into scope. This meshes well with the agile notion that you only build the things you need and that you don’t “borrow trouble from the future”. In larger teams, this can often break down, however, as if something is needed in the near term, it can be harder to tell how soon it will be needed. Worse, if it is needed, large swaths of the team could be blocked from getting their work done if the feature isn’t implemented. To fix this, as teams get larger, you are probably going to have to do more planning up front, with an eye towards identifying potential blocking features that are on your project’s critical path, well before they act as blocking issues for getting work done. For instance, let’s say that you are adding an enterprise message bus to your application. In a small team,