4 ms·

Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structu

Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software components to peoples livelihoods.

mjburgess 6y ago
> Don't tie the existence of internal software components to peoples livelihoods. The claim is that such ties, at the macro-structure level, are inevitable and exist regardless. The point is then to determine the best way either to restructure the organisation, or, the code base, to cope.
- strictfp 6y ago
  I think the ties arise because people are actively seeking areas of responsibility. Software components are an obvious grab if your eyes are on the software specifically. But there are other ways of dividing your teams; based on for instance customers, use-cases, aspects of the code (performance, security). The problem is that the software usually keeps expanding until programmers find it hard to cope. If you split teams up so that some people are only concerned with a certain part of the codebase, chances are you are going to grow the size of the codebase by a quite large factor. I think there should be an incentive in place to keep the codebase small and understandable by most.
jhrmnn 6y ago
It's pretty hard to keep the design open once the whole architecture is bigger than what a single programmer can keep track of. Say, the Linux kernel. The overall architecture is fixed, there's no way around it. At that point, splitting into components that are maintained separately does no harm. AFAIK the Linux kernel is maintained like that already in practice, even if it's a single repo.
- strictfp 6y ago
  I agree with you in such cases, but I'm willing to bet that most codebases don't need to be as big as they are, and that it's better to create an incentive to collaborate and keep the codebase maintanable and small.
pjc50 6y ago
The opposite of "has a team around it" is "abandoned". Or at least low down on somebody's priority list.
- strictfp 6y ago
  That's generally true, and it's a big problem with microservices, because they need so much upkeep. But if your code is living as a few hundred or thousand readable lines in the common codebase, that isn't really a problem. The code is there, readable and working, and if anyone needs to change it they can. If it falls out of fashion, it can be deleted.
yowlingcat 6y ago
What is your alternative? Tying "the existence of internal software components to people's livelihoods" across the expanse of the entire codebase is the only remotely effective approach I've seen to scaling the SDLC at scale.
- cturner 6y ago
  "What is your alternative?" Aggressively small teams, with no hands-off middle-management layer. You can build massive capability around a small number of well-managed message-backbones and a single codebase. By keeping the number of hands small and the structure flat, you force high standards. (Skilled staff won't tolerate distractions caused by bad engineering or inadequate automation.) Heuristic for analysing firms: who has strategic power in decision-making? Conventional answer: a group of hands-off middle-managers who run on meeting tempo, and who are valued by how many people and systems report into them. Under AST: an engineering effort running on maker tempo in cooperation with a hands-on sales effort. Microservices tend to have multilateral contracts with other systems in the organisation. This steers all planning towards meetings. This creates middle-management bloat.
  - herval 6y ago
    Is there any example where this works (articles, presentations, etc)? In particular, anywhere with more than a couple dozen developers?
    - dodobirdlord 6y ago
      Amazon has a famous love for what they call “two-pizza teams” and you can find writeups about the philosophy by searching the term. The joke is that a team should be small enough that you only need to order two pizzas to feed them all. The philosophy is about the number of participants in the decision-making process. Keep teams small and give them total ownership of decision making so that decisions can be made by a small group of people who work with each other every day. That way no meetings (and certainly no cross-team meeting) need to happen for most decisions to be made.
michaelcampbell 6y ago
I've seen this pendulum swing both ways, often within an organization. Cross functional teams owning code bases allows divergence to specialize and ownership of a release, teams with a single functional focus allows efficiency of work and cross cutting gains. Both have their boatloads of suck, neither is inherently better. Interestingly, trying to mix them to get the benefits of each doesn't seem to invalidate any of their downsides; often it exacerbates them.
deleted 6y ago
[deleted]

mjburgess 6y ago

> Don't tie the existence of internal software components to peoples livelihoods. The claim is that such ties, at the macro-structure level, are inevitable and exist regardless. The point is then to determine the best way either to restructure the organisation, or, the code base, to cope.

strictfp 6y ago
I think the ties arise because people are actively seeking areas of responsibility. Software components are an obvious grab if your eyes are on the software specifically. But there are other ways of dividing your teams; based on for instance customers, use-cases, aspects of the code (performance, security). The problem is that the software usually keeps expanding until programmers find it hard to cope. If you split teams up so that some people are only concerned with a certain part of the codebase, chances are you are going to grow the size of the codebase by a quite large factor. I think there should be an incentive in place to keep the codebase small and understandable by most.

jhrmnn 6y ago

It's pretty hard to keep the design open once the whole architecture is bigger than what a single programmer can keep track of. Say, the Linux kernel. The overall architecture is fixed, there's no way around it. At that point, splitting into components that are maintained separately does no harm. AFAIK the Linux kernel is maintained like that already in practice, even if it's a single repo.

strictfp 6y ago
I agree with you in such cases, but I'm willing to bet that most codebases don't need to be as big as they are, and that it's better to create an incentive to collaborate and keep the codebase maintanable and small.

pjc50 6y ago

The opposite of "has a team around it" is "abandoned". Or at least low down on somebody's priority list.

strictfp 6y ago
That's generally true, and it's a big problem with microservices, because they need so much upkeep. But if your code is living as a few hundred or thousand readable lines in the common codebase, that isn't really a problem. The code is there, readable and working, and if anyone needs to change it they can. If it falls out of fashion, it can be deleted.

yowlingcat 6y ago

What is your alternative? Tying "the existence of internal software components to people's livelihoods" across the expanse of the entire codebase is the only remotely effective approach I've seen to scaling the SDLC at scale.

cturner 6y ago
"What is your alternative?" Aggressively small teams, with no hands-off middle-management layer. You can build massive capability around a small number of well-managed message-backbones and a single codebase. By keeping the number of hands small and the structure flat, you force high standards. (Skilled staff won't tolerate distractions caused by bad engineering or inadequate automation.) Heuristic for analysing firms: who has strategic power in decision-making? Conventional answer: a group of hands-off middle-managers who run on meeting tempo, and who are valued by how many people and systems report into them. Under AST: an engineering effort running on maker tempo in cooperation with a hands-on sales effort. Microservices tend to have multilateral contracts with other systems in the organisation. This steers all planning towards meetings. This creates middle-management bloat.
- herval 6y ago
  Is there any example where this works (articles, presentations, etc)? In particular, anywhere with more than a couple dozen developers?
  - dodobirdlord 6y ago
    Amazon has a famous love for what they call “two-pizza teams” and you can find writeups about the philosophy by searching the term. The joke is that a team should be small enough that you only need to order two pizzas to feed them all. The philosophy is about the number of participants in the decision-making process. Keep teams small and give them total ownership of decision making so that decisions can be made by a small group of people who work with each other every day. That way no meetings (and certainly no cross-team meeting) need to happen for most decisions to be made.

michaelcampbell 6y ago

I've seen this pendulum swing both ways, often within an organization. Cross functional teams owning code bases allows divergence to specialize and ownership of a release, teams with a single functional focus allows efficiency of work and cross cutting gains. Both have their boatloads of suck, neither is inherently better. Interestingly, trying to mix them to get the benefits of each doesn't seem to invalidate any of their downsides; often it exacerbates them.

deleted 6y ago

[deleted]