7 ms·

> "Everyone owns architecture" I don't agree with this. It appeals to our sense of egalitarianism, but in practice I haven't seen it work out well. Ideally o

> "Everyone owns architecture" I don't agree with this. It appeals to our sense of egalitarianism, but in practice I haven't seen it work out well. Ideally one or at most a few people, who are also developers, owns the architecture, so that it is consistent. They should be senior developers who still work on real features in the code base to avoid architecture astronautism. Consistency in architecture is more important than genius in architecture in most cases. Let a thousand flowers bloom elsewhere in your life.

danwee 4y ago
I read it more as "everyone (in the team) should be responsible for the architecture (of their products)". So, it's the duty of every engineer (even junior ones) to get to know more about the architecture of their products or to come up with decent architectures for future ones. Of course, some engineers know more than others (or have better taste). That's fine. It's pretty common nowadays that only the "tech lead" or the most senior engineers discuss architectural topics that affect the whole team, but the most junior engineers are left behind.
- oppositelock 4y ago
  I'm the tech lead of a sizable team, and what you describe, leaving junior engineers behind, would be a sign of failure on me. Large software systems are complex, and there is too much detail for any one person to dive deep into everything, so in my opinion, you discuss overall architecture with the team, but critically, you explain _why_ you are proposing a certain approach, because more junior people don't have this context. Then, you ask the other folks to help you go deep into investigations on whether your architecture is compatible with the details. If as a TL, you are not teaching and nurturing your young 'uns, you're doing a bad job.
  - ric129 4y ago
    What if your young 'uns just do not... participate? I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic
    - oppositelock 4y ago
      This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership. In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.
      - waynesonfire 4y ago
        > lack of participation comes from a lack of self confidence Yep that's it... let's not have management or leadership take any responsibility. It's the subordinates fault of course.
- AnimalMuppet 4y ago
  One place I worked, there was an architecture. The intent was that every programmer on the project could reproduce the same diagram of the architecture on a cocktail napkin. The reason is so that all programmers can keep the architecture in their head, to help guide their work. If they have to go look it up, they probably won't. To make this work, the architecture needs to be somewhat simple. Architecture astronautics fail the "everyone can keep it in their head" test. I think they stole that idea (everybody has the architecture in their head) from Extreme Programming.
jollyllama 4y ago
This works well, so long as it's the official policy. If the official messaging is "we need to incorporate everyone's perspective", but the actual policy is "you can implement any pattern you want so long as it's our pattern", it becomes unbearable.
leonidasv 4y ago
This reminds me of an old quote that says: "A dog with two owners dies of hunger".
- Rayhem 4y ago
  Curious. Cats with multiple owners/friends are notorious for finding ways to get fed repeatedly.
  - leonidasv 4y ago
    That's because cats don't have owners, they have staff.
Foobar8568 4y ago
And the architect who imposes an architecture should also design the interface between components.
curun1r 4y ago
I think it’s important that everyone feels like they own the architecture. In practice, it means that everyone puts in ideas and the person or persons in charge only (gently) nix the ideas that don’t fit with their vision. But it’s important that everyone not feel stifled by a heavy-handed architectural vision that’s dictated from on high. In tech, there’s often many right answers and a leader’s job is to ensure the team lands on one of them, not necessarily the leader’s favorite one. You’ll end up with far more inconsistencies if you have high employee turnover. Team cohesion is often more important than getting all the technical details perfect.
- recursivedoubts 4y ago
  the noble lie vs. the sympathetically-delivered horrible truth
  - curun1r 4y ago
    It’s more like a noble half truth, since the architect leaves themselves open to accepting a good idea that isn’t their own.
- trhoad 4y ago
  > it means that everyone puts in ideas and the person or persons in charge only (gently) nix the ideas that don’t fit with their vision This. Architects have to have a really quite rare blend of skills: superbly diplomatic yet inclusive, and ideally in it for the long-haul.
- waynesonfire 4y ago
  > I think it’s important that everyone feels like they own the architecture. You can keep your _feelings_ ... takes a few iterations to spot this toxic bullshit. Be explicit. Not everyone needs to get a participation star. The hired developers that were tricked into a false development process will eventually call out this bs and leave. Depending how gullible they are may take them longer. I dont need to feel like I'm being heard. I need you to hear me if you're going to ask.
dalbasal 4y ago
Imo, the bigger question is big or small architecture. Who owns it becomes derivative of that.
bob1029 4y ago
I say it all the time. The maximum # of chefs who should be permitted in the architecture & design kitchen on day 1 is exactly one. You always want the person with the most experience and willingness to endure pain to undertake these efforts. Building new, coherent architecture that your team will be willing to follow for years or decades is non-trivial and not something you can learn by going to college and/or consuming a bunch of bullshit tutorials from the internet. Architecture cannot be forked or cloned. It must be applied uniquely to the problem at hand. To continue the analogy - You simply have to have tried to make that pasta dish so many fucking times that you become god of pasta dishes. You need to have customers (and employees) complain at you for 2 decades about various aspects of your cooking for you to truly understand what works and what doesnt. > Consistency in architecture is more important than genius in architecture in most cases Absolutely agree. This is why suggestions like "just use 1 big database for everything" are automatically a leap in the right direction for all involved. Only when this starts to get yucky should you turn on the clever bits of your brain. The specific code arrangement is not that important, as long as the team understands some common domain model (types, properties & relations). The most successful architecture is one that the entire team can understand and communicate about without a senior developer babysitting them.
- recursivedoubts 4y ago
  from one grug to another grug... https://grugbrain.dev https://grugbrain.dev
- pydry 4y ago
  Two people with 15 years experience will have experienced a different 15 years. Both are usually more valuable brought together. If you make one of those people the "God of architecture" you're not only going to piss off the other one you will probably lose the benefit of their experience. If theyre not responsible for architecture they'll pay commensurately less attention to it. Thats a waste of a salary. The only scenario I can think of where it to promote one above all others would really be worth it would be if you otherwise cant stop the team from bickering. As for juniors - if anything I tend to feel like theyre too deferent even when encouraged to speak up and take ownership. The only exception is when they dont realize they are making an architectural decision.
angarg12 4y ago
I work in big tech, and that's pretty much how it works here. We don't have "architect" roles, instead every engineer owns a certain part of the system. The difference is scale and complexity: a mid level developer might design a feature or microservice, while staff developers own the architecture of entire systems. Senior/Staff engs oversee the overall system and delegate ownership of parts or subsystems to other devs. Your concerns about consistency are addressed with things like design reviews and regular updates.
motbus3 4y ago
completely agree

danwee 4y ago

I read it more as "everyone (in the team) should be responsible for the architecture (of their products)". So, it's the duty of every engineer (even junior ones) to get to know more about the architecture of their products or to come up with decent architectures for future ones. Of course, some engineers know more than others (or have better taste). That's fine. It's pretty common nowadays that only the "tech lead" or the most senior engineers discuss architectural topics that affect the whole team, but the most junior engineers are left behind.

oppositelock 4y ago
I'm the tech lead of a sizable team, and what you describe, leaving junior engineers behind, would be a sign of failure on me. Large software systems are complex, and there is too much detail for any one person to dive deep into everything, so in my opinion, you discuss overall architecture with the team, but critically, you explain _why_ you are proposing a certain approach, because more junior people don't have this context. Then, you ask the other folks to help you go deep into investigations on whether your architecture is compatible with the details. If as a TL, you are not teaching and nurturing your young 'uns, you're doing a bad job.
- ric129 4y ago
  What if your young 'uns just do not... participate? I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic
  - oppositelock 4y ago
    This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership. In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.
    - waynesonfire 4y ago
      > lack of participation comes from a lack of self confidence Yep that's it... let's not have management or leadership take any responsibility. It's the subordinates fault of course.
AnimalMuppet 4y ago
One place I worked, there was an architecture. The intent was that every programmer on the project could reproduce the same diagram of the architecture on a cocktail napkin. The reason is so that all programmers can keep the architecture in their head, to help guide their work. If they have to go look it up, they probably won't. To make this work, the architecture needs to be somewhat simple. Architecture astronautics fail the "everyone can keep it in their head" test. I think they stole that idea (everybody has the architecture in their head) from Extreme Programming.

jollyllama 4y ago

This works well, so long as it's the official policy. If the official messaging is "we need to incorporate everyone's perspective", but the actual policy is "you can implement any pattern you want so long as it's our pattern", it becomes unbearable.

leonidasv 4y ago

This reminds me of an old quote that says: "A dog with two owners dies of hunger".

Rayhem 4y ago
Curious. Cats with multiple owners/friends are notorious for finding ways to get fed repeatedly.
- leonidasv 4y ago
  That's because cats don't have owners, they have staff.

Foobar8568 4y ago

And the architect who imposes an architecture should also design the interface between components.

curun1r 4y ago

I think it’s important that everyone feels like they own the architecture. In practice, it means that everyone puts in ideas and the person or persons in charge only (gently) nix the ideas that don’t fit with their vision. But it’s important that everyone not feel stifled by a heavy-handed architectural vision that’s dictated from on high. In tech, there’s often many right answers and a leader’s job is to ensure the team lands on one of them, not necessarily the leader’s favorite one. You’ll end up with far more inconsistencies if you have high employee turnover. Team cohesion is often more important than getting all the technical details perfect.

recursivedoubts 4y ago
the noble lie vs. the sympathetically-delivered horrible truth
- curun1r 4y ago
  It’s more like a noble half truth, since the architect leaves themselves open to accepting a good idea that isn’t their own.
trhoad 4y ago
> it means that everyone puts in ideas and the person or persons in charge only (gently) nix the ideas that don’t fit with their vision This. Architects have to have a really quite rare blend of skills: superbly diplomatic yet inclusive, and ideally in it for the long-haul.
waynesonfire 4y ago
> I think it’s important that everyone feels like they own the architecture. You can keep your _feelings_ ... takes a few iterations to spot this toxic bullshit. Be explicit. Not everyone needs to get a participation star. The hired developers that were tricked into a false development process will eventually call out this bs and leave. Depending how gullible they are may take them longer. I dont need to feel like I'm being heard. I need you to hear me if you're going to ask.

dalbasal 4y ago

Imo, the bigger question is big or small architecture. Who owns it becomes derivative of that.

bob1029 4y ago

I say it all the time. The maximum # of chefs who should be permitted in the architecture & design kitchen on day 1 is exactly one. You always want the person with the most experience and willingness to endure pain to undertake these efforts. Building new, coherent architecture that your team will be willing to follow for years or decades is non-trivial and not something you can learn by going to college and/or consuming a bunch of bullshit tutorials from the internet. Architecture cannot be forked or cloned. It must be applied uniquely to the problem at hand. To continue the analogy - You simply have to have tried to make that pasta dish so many fucking times that you become god of pasta dishes. You need to have customers (and employees) complain at you for 2 decades about various aspects of your cooking for you to truly understand what works and what doesnt. > Consistency in architecture is more important than genius in architecture in most cases Absolutely agree. This is why suggestions like "just use 1 big database for everything" are automatically a leap in the right direction for all involved. Only when this starts to get yucky should you turn on the clever bits of your brain. The specific code arrangement is not that important, as long as the team understands some common domain model (types, properties & relations). The most successful architecture is one that the entire team can understand and communicate about without a senior developer babysitting them.

recursivedoubts 4y ago
from one grug to another grug... https://grugbrain.dev https://grugbrain.dev
pydry 4y ago
Two people with 15 years experience will have experienced a different 15 years. Both are usually more valuable brought together. If you make one of those people the "God of architecture" you're not only going to piss off the other one you will probably lose the benefit of their experience. If theyre not responsible for architecture they'll pay commensurately less attention to it. Thats a waste of a salary. The only scenario I can think of where it to promote one above all others would really be worth it would be if you otherwise cant stop the team from bickering. As for juniors - if anything I tend to feel like theyre too deferent even when encouraged to speak up and take ownership. The only exception is when they dont realize they are making an architectural decision.

angarg12 4y ago

I work in big tech, and that's pretty much how it works here. We don't have "architect" roles, instead every engineer owns a certain part of the system. The difference is scale and complexity: a mid level developer might design a feature or microservice, while staff developers own the architecture of entire systems. Senior/Staff engs oversee the overall system and delegate ownership of parts or subsystems to other devs. Your concerns about consistency are addressed with things like design reviews and regular updates.

motbus3 4y ago

completely agree