There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, people lose autonomy and can't fully act on their own vision.
The alternative is to think up new architectures and team structures that allow more people more freedom to work.
If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere.
Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code.
> Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your choices for the benefit of the wider team results in much better code.
This becomes more and more important as the team grows, as there are more feet that you can step on. Working on a large team is really different than a solo or small team. Large teams are as much about communication, mutual respect, and shared goals than writing good code. Unfortunately, communication takes time and energy, and necessarily slows down the entire process, but it's critical.
The Mythical Man Month lays this out nicely. The possible lines of communication in a N person team grows quadratically at N*(N-1), which explains why large teams are often far less efficient on a per-person basis than smaller ones.
Good point. I think what you're hinting at is good if all or the vast majority of people are on board. In my experience this is not generally the case. People usually climb up the authority ladder not because they are emphatic toward others, or because they compromise on their choices to help the team, but because they solve technical problems and deliver product to customers, often while cutting corners and making executive decisions in the code base. More junior and newer people are at the whim of these more senior people, regardless of whatever egregious technical decisions they like to make.
The microservice approach has its own problems but hints toward a direction where teams are small and autonomous, with ground-up freedom on the architecture of their little service and free from draconian oversight. I'm not an advocate of microservices, but it's an approach that hints at something different.
The trouble is that in closely cooperating teams where I worked, people who did what you suggest ended up in submissive position against people who just do their thing ignoring others. If I proactive think about others and you don't, you get to work however you like it oftentimes making my work more difficult - while I am more restricted and have harder time to make my ideas reality.
I meant team without clear responsibilities and "turfs" supposed to work together :). Clear reasonable responsibilities are an awesome thing and kill whole bunch of insecurities and resulting behavior.
in a professional context requiring collaboration, that's an asshole move, and people who do that sort of thing on a regular basis should be reprimanded.
A good alternative to this that I have found is peer review: everybody gets their code reviewed by at least one other person on the team. Everybody gets to work autonomously initially, and everybody gets their code checked by the rest of the team.
Strict hierarchies suck because if you're a leaf in the hierarchy, it's very difficult to collaborate or work with other leafs that are not in your same sub-branch.
A flat fully connected hierarchy is better for small groups, but it doesn't scale well as the number of lines of communications is proportional to the square of the number of people.
A large set of small loosely-connected groups is an alternative. Groups can communicate with other groups on a need basis. This might be a pipe dream. Some would argue that the emergence of an uber-group that every other group must subordinate to is imminent.
That's a non-sequitur, I guess you mean if every sender sends one message per listener. I don't think it's a broad cast if it targets sole recipients per message.
Quite literally, I think, it could be modeled as a vector space in linear algebra. Each signal is in frequency space, which can be found from the fourier transform integrating the temporal space over different bandwidth channels per sender. You get N² only if the message size is proportional to N, if you will.
> If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere.
"everyone writes it" in the long term can still allow specific people to write/fix/augment/refactor/etc specific parts in the short to medium term. i think it's a good goal to never have a part of the code that less than two or three people can maintain, but preferably more (depending on size of team(s) and codebase(s), obviously). i think this generally results in better quality code, and higher bus factor is inherently a good thing anyway.
i used to be kind of against style guides and style checking. but a not-too-rigid set of style norms, the willingness to bend or discard them when justified, and a generally well-behaved group of people that can collaborate well and agree that shared understanding has a lot of inherent value... those things together can get you a good codebase where "everyone writes some of it", or at least everyone can deal with most of it, even if people might have areas of expertise. nowhere near a panacea, and not even necessary depending on the team, but it can be useful even if it means people give up style tics they love or tolerate ones they hate. it also mechanically eliminates a lot of the temptation to nitpick a whole class of things that probably doesn't deserve nearly as much nitpicking as it'd get in code review, because everyone thinks their own personal taste matters more than it actually does (me included, that's why i used to not like style guides).
all the above is much easier if everyone's able to keep their ego in check, be collegial, enjoy the challenge of justifying decisions and accepting constructive criticism, etc. i guess that can be an unfortunately difficult setup to come by, but i've been really lucky on that front, by and large.
> To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors.
if you have what i described above, peer level code review with team leads and managers for the occasional tie breaker should work fine the vast majority of the time.
> In this process, people lose autonomy and can't fully act on their own vision.
if you work on a team, you have to work toward shared goals and vision. if a person wants to fully act on their own vision, they should be self-employed in a company of one (though they'll still be subject to market forces). if you're collaborating, you're necessarily involved in a shifting balance of autonomy, delegation, and being delegated to (which is often but not always where the autonomy comes in).
Great points. By "act on their own vision" I mean technical vision, the how to solve a problem, not which problem to solve. In my experience this is where many engineers become depressed and want to quit. They're interested in the problems the company is solving, but when implementing solutions they become bogged down in myriad rules with which they do not agree. Coding style is simple enough to adapt to. Having to follow a technology stack, core architecture, and core APIs that you find unintuitive is harder. In fact I'd venture to say (as a corollary of Conway's law) that companies that follow the "everybody writes some of it" style breed narrow monocultures, where everybody sees things roughly the same way.
The alternative is to think up new architectures and team structures that allow more people more freedom to work.