Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Imagine interpreting that as advice on how you should try to design things, lol.
Tbf, I think most of the post is just typical LinkedIn fluff, but I didn’t want to take the poor fellow out of context.
So I don’t wholly disagree with your point, but even if I take that context at face value it still comes off as “ hey if your orgs are designed in perfect harmony w/ your objectives, your product will meet those objectives”.
Sure that’s logical as far as it goes, but it’s pretty much never the case in practice that you have a context that’s actually optimized to needs like that.
I read it similar, but also kind of from the other side: If your organization is set up in a way that ignores the technical requirements of the product, your are going to have a bad time.
And yes, of course this is more often on the bad side than on the good side in practice. If everything was already fine most of the time, there would be no point in discussing this topic.
I feel like the subtext the post doesn’t say explicitly is that most management structure are not setup this way and thus software projects end up with a non-optimal design.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
So I don’t wholly disagree with your point, but even if I take that context at face value it still comes off as “ hey if your orgs are designed in perfect harmony w/ your objectives, your product will meet those objectives”.
Sure that’s logical as far as it goes, but it’s pretty much never the case in practice that you have a context that’s actually optimized to needs like that.
I read it similar, but also kind of from the other side: If your organization is set up in a way that ignores the technical requirements of the product, your are going to have a bad time.
And yes, of course this is more often on the bad side than on the good side in practice. If everything was already fine most of the time, there would be no point in discussing this topic.
I feel like the subtext the post doesn’t say explicitly is that most management structure are not setup this way and thus software projects end up with a non-optimal design.
That is pretty much a given. Why else write about it at all?