We all want to write good code, and there is no shortage of advice on how to do that. SOLID. SOA. SRP. LoD. These are important – without them, we’d all be writing lousy code. But none of them address the single factor that has the biggest impact on the quality of a codebase. That factor is Other People.
The people you’re working with affect the codebase more than you do, in aggregate, if there’s more than a few of them. And it’s not just the individuals. How your team is organized, how it’s managed, and how it communicates all leave unmistakeable fingerprints on the code. Over time, a codebase grows to resemble its creators, reflecting the good and the ugly of the individuals, as well as the good and the ugly of their relationships.
This is not always a disaster. But it means that a team of really smart individuals can, together, end up writing terrible code. And it means that a lot of issues that get labeled “software design problems” cannot be solved by merely applying the right software design principle. A team can struggle with a problem like this for months, and then a small, often-inadvertent adjustment to the team dynamics makes the problem suddenly tractable.
I’ll show you some common “design” problems in Rails applications that actually stem directly from the structure of a dysfunctional team. I’ll talk about what you can do to solve them, and I’ll give you some tools for distinguishing between those types of issues and plain old lousy code. You’ll gain a new appreciation for the invisible forces that guide our design decisions day-to-day.
Video producer: http://rubyconf.org/