4 ms·

I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to under

by cjonas 4y ago

I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to understand the point. The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...

toss1 4y ago
...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ? That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up. They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems. Now everyone pays.
- imtringued 4y ago
  The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.
  - toss1 4y ago
    I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype. It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules. Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.
- cjonas 4y ago
  I'll be the one who gets blamed for that, but not how to do so without well defined and properly verified requirements. (see point about about the not understanding what is being built and constantly changing the scope)

by cjonas 4y ago

toss1 4y ago

...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ? That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up. They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems. Now everyone pays.

imtringued 4y ago
The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.
- toss1 4y ago
  I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype. It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules. Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.
cjonas 4y ago
I'll be the one who gets blamed for that, but not how to do so without well defined and properly verified requirements. (see point about about the not understanding what is being built and constantly changing the scope)