|
Perhaps less about programming and more about society, I'm really not a fan of simple "majority rules democracy" or consensus building—which feels more like an enhanced version of the former than a distinct approach. Either approach is, in its own way, autocratic and ultimately bulldozes over anyone whose views and preferences don't match up well enough. Instead, I'm fascinated with systems designed to robustly let people actively disagree but still coexist and work together. The goal is not to sway people's views or push them in a certain direction, but to allow different people to hold to different, possibly conflicting, outlooks and still coexist peacefully and productively. This way, even if you hold some minority preferences—everyone is different, so this is not a surprise—you're still free to do your thing. That's, coincidentally, one of the reasons I'm a fan of some sort of capitalism: capitalism manages to optimize for everyone without needing a single goal handed down from above—or passed up from below. In a word: decentralization. And you know, this could be applied to software too. Why does everyone at your company need to do everything in the same way? Sure, you'll get some minor advantages in compatibility, and it will be easier for people to move from project to project, but those advantages are limited—but very visible. I believe they're overvalued for just this reason: experience pushes people away from problems that are clear but not ones that are subtle. So, from this point of view, I really like how some modern companies (Facebook and Prezi come to mind) are starting to organize small teams in self-contained ways. You expose and support a particular interface to the rest of the company, but can use whatever languages and whatever technologies you want internally. Then, instead of the whole company being a big, uniform blob of interconnections, you have a disparate network of self-contained systems with clear interfaces. With this approach, each team can work with whatever technology fits their problem—and them—best. Moreover, you get the advantages of low coupling within your internal technologies, because the teams are, by necessity, distinct. Now all this needs is a catchy name to rival "consensus-driven development". "Decentralized development", perhaps? It's alliterative. |