5 ms·

This isn't bad advice, but I would add to it. If you're a large organization and building in such a way that large groups need to understand the details of what

by madrox 8y ago

This isn't bad advice, but I would add to it. If you're a large organization and building in such a way that large groups need to understand the details of what you're doing, then you're doing it wrong. Ideally speaking, implementations can be worked through with small groups. Only the interfaces need to be exposed and documented. Unless you're doing something beyond CRUD, drowning teams in unnecessary details often result in distraction. The arguments against this I usually hear are about things like security audits, architecture reviews, and other internal processes designed to ensure engineering quality. However, I'd encourage these teams to also think like platforms that have machine interfaces. People make terrible APIs.

taeric 8y ago
I've had this debate in the office. It is, potentially, one of the start examples of where "service oriented architecture" shines. Define the service interface between the teams, and let them do the rest. Unfortunately, it is too easy to actually talk of a shared infrastructure design. As soon as you have a shared message queue/repository or some other piece of infrastructure, you no longer have a solid contract between teams where each can operate independently of the other.
- madrox 8y ago
  Oh for sure, this is way easier to say than do. More often than not some team's interface isn't quite what you need, so then you have to have some way of working between teams to make sure the interfaces improve, and then what do you do while you wait for that to happen? But I've seen large orgs that at least strive for this ideal vs orgs that have thrown their hands in the air and given up. One is definitely a lot easier to operate in.
closeparen 8y ago
An RFC says "heads up, I'm planning to make a change." If the tagline doesn't seem relevant to your world, you simply ignore it.
- madrox 8y ago
  The difficulty is that quite often you don't know until you understand the change. Better to operate in a world where things that impact you don't come through RFCs.
vageli 8y ago
> This isn't bad advice, but I would add to it. If you're a large organization and building in such a way that large groups need to understand the details of what you're doing, then you're doing it wrong. > Ideally speaking, implementations can be worked through with small groups. Only the interfaces need to be exposed and documented. Unless you're doing something beyond CRUD, drowning teams in unnecessary details often result in distraction. This is assuming that attrition is not a thing. The set of engineers that are on your team is likely smaller than the total number of engineers that will ever work on your project. When people want to know six months from now why you chose RabbitMQ over other tech at the time, having an RFC lets you point to an artifact versus conjecture on past motivations.
- toast0 8y ago
  Do the reasons for the choice six months ago even matter today? Today you have six months of history of it being a good choice or not. And six months of development assuming it was the choice, that may or may not apply to something else. And the choices available today have likely changed from six months ago, too. (I'm a little concerned about your team that has no connection to decisions from six months ago, but we can adjust the time frame and the rest still applies)
  - seb1204 8y ago
    Of course they matter. Ideally the decision that was made 6 months ago under the conditions/restraints was the right one back then. Since then circumstances might have changed that would result in a different decision 6 months ago if you had known. Only if you have a record of some sort (ideally with background information and not just the time of the decision) people will be able to understand and re-evaluate the past. Money and time was invested since then and the decision to keep the course or to change again should consider the history of the decision.

by madrox 8y ago

taeric 8y ago

I've had this debate in the office. It is, potentially, one of the start examples of where "service oriented architecture" shines. Define the service interface between the teams, and let them do the rest. Unfortunately, it is too easy to actually talk of a shared infrastructure design. As soon as you have a shared message queue/repository or some other piece of infrastructure, you no longer have a solid contract between teams where each can operate independently of the other.

madrox 8y ago
Oh for sure, this is way easier to say than do. More often than not some team's interface isn't quite what you need, so then you have to have some way of working between teams to make sure the interfaces improve, and then what do you do while you wait for that to happen? But I've seen large orgs that at least strive for this ideal vs orgs that have thrown their hands in the air and given up. One is definitely a lot easier to operate in.

closeparen 8y ago

An RFC says "heads up, I'm planning to make a change." If the tagline doesn't seem relevant to your world, you simply ignore it.

madrox 8y ago
The difficulty is that quite often you don't know until you understand the change. Better to operate in a world where things that impact you don't come through RFCs.

vageli 8y ago

> This isn't bad advice, but I would add to it. If you're a large organization and building in such a way that large groups need to understand the details of what you're doing, then you're doing it wrong. > Ideally speaking, implementations can be worked through with small groups. Only the interfaces need to be exposed and documented. Unless you're doing something beyond CRUD, drowning teams in unnecessary details often result in distraction. This is assuming that attrition is not a thing. The set of engineers that are on your team is likely smaller than the total number of engineers that will ever work on your project. When people want to know six months from now why you chose RabbitMQ over other tech at the time, having an RFC lets you point to an artifact versus conjecture on past motivations.

toast0 8y ago
Do the reasons for the choice six months ago even matter today? Today you have six months of history of it being a good choice or not. And six months of development assuming it was the choice, that may or may not apply to something else. And the choices available today have likely changed from six months ago, too. (I'm a little concerned about your team that has no connection to decisions from six months ago, but we can adjust the time frame and the rest still applies)
- seb1204 8y ago
  Of course they matter. Ideally the decision that was made 6 months ago under the conditions/restraints was the right one back then. Since then circumstances might have changed that would result in a different decision 6 months ago if you had known. Only if you have a record of some sort (ideally with background information and not just the time of the decision) people will be able to understand and re-evaluate the past. Money and time was invested since then and the decision to keep the course or to change again should consider the history of the decision.