So I’ve been accused, more than once, of obsessing over organizational structures. Heck, I just waxed poetically about Conway’s Law recently, and that was just after leading a couple of sessions at a conference on, specifically, “Structuring Teams for Scale”.
Which was why I got all excited in coming across this tweet the other day:
Absolutely right! This is an incredible aspect of Conway's Law that people forget about! ** Code is a cultural artifact!! **
— Peter Wang 🦋 (@pwang) March 1, 2019
Which is why open source is not about licenses, but about how transparency gives rise to patterns of collaboration that enable better,faster innovation. https://t.co/bCvL3ml1nM
It’s an incredible statement, even outside its commentary here on the organization1 of open-sourced software. This insight gets at the heart of code and software systems—the people—and acknowledges their central role how software is built and maintained, how its structure evolves according to the relationships, again, of collections of individuals. In this case, “culture” encompasses the rules and norms that govern these person-to-person interactions.
It’s natural to ask—if the relationship between how people are organized and the code they output is indeed causal, then what qualities of the resultant code should be attributed to the structure of coders? How much does a messy codebase imply underlying developer chaos? Conversely, are well-thought-out systems and interfaces a trailing indicator of well-defined teams and roles? How much archaeological data can be mined from a cultural artifact?
Do the repos of renowned tech companies actually look like how they’re supposedly organized2?
All that said, while it’s certainly fun to test the explanatory depth of that statement, there’s more utility in using it as a predictive tool; establishing and maintaining a set of cultural values will result in technology that reflects those norms. In a way, it’s a restatement of the lesson of one of my favorite management books, The Score Takes Care of Itself, whereby eventual success is merely a byproduct of maintaining a high standard of performance. Good code will eventually flow out of a well-functioning team, so most of the effort should go towards its construction.
