3 ms·

This is all outlined by Fred Brooks in 1975. I've beat this dead horse before, but I suppose I'll beat it again. In the late '90s and early aughts everyone rea

This is all outlined by Fred Brooks in 1975. I've beat this dead horse before, but I suppose I'll beat it again. In the late '90s and early aughts everyone read Mythical Man-Month. There is even a law attributed to him, Brooks' law [1]. It really feels like no one internalized what he was actually saying. I suppose in a world of trends and fads, timeless advice is hard to recognize. > [...] the increased communication overhead will consume an ever-increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added. Microservices, of course, exasperate this by actually increasing the communication required to make software. [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month

eloff 6y ago
> Microservices, of course, exasperate this by actually increasing the communication required to make software. I HATE microservices. I've never seen them used appropriately, although I imagine it can be done. But I think if you increase human communication by using microservices you're defeating the raison d'etre of microservices. That's not the fault of microservices - it's the fault of the humans using them badly or where they shouldn't. Story time. I once contracted to a fortune 500 doing a $100M total rewrite with literally 100 microservices all in their own git repo. It was such a disaster I contemplated shorting their stock. I don't know how the story ended, but I feel confident it didn't end well.
- TheCoelacanth 6y ago
  Microservices can be okay, but they are greatly overused. They are a solution for very large organizations with a ton of teams. For 100 micro-services to make any sense at all, you need to have at least 200-300 developers. Total rewrites, on the other hand, are never anything other than a complete and unmitigated disaster. The only way that you can possibly make a $100M rewrite successful is to do it Ship of Theseus style, where the rewritten code is incorporated into the working and actively-used production software long before the full rewrite is complete. Even then, the full rewrite usually won't complete, so you need to make sure that project is still useful even if you only do a partial rewrite.
  - TwoBit 6y ago
    Has there ever been a large scale successful rewrite? How much of Netscape/Firefox was rewritten from the ground up?
  - eloff 6y ago
    Full rewrites are usually almost always a disaster. I should know, I've done a few on side projects. This case was a dramatic example of that. > For 100 micro-services to make any sense at all, you need to have at least 200-300 developers. Yeah, at minimum. I think these guys were running at least 2 microservices per developer. That made no sense to me.
  - justin_oaks 6y ago
    I've heard of the "Ship of Theseus" rewrites as a recommendation for "evolution, not revolution". I agreed that the big rewrite (i.e. "revolution") is usually a disaster.
dalbasal 6y ago
Yet... the economics of software is such that software companies balloon in size. Software companies/teams/applications of today are many time larger than in 1975. It may be more efficient to have software that's federated and developed by small teams but... Facebook's revenue is $90bn. A social network 10% FB's "size" will make much less than $9bn in ad revenues^. That means that product teams grow until the point Fred Brooks warned about play out... until the marginal team members' contribution is negative. ^For example, Reddit has 10%-20% facebook's users, but only about 2% of its revenue.
marcinzm 6y ago
>Microservices, of course, exasperate this by actually increasing the communication required to make software. I'd argue the exact opposite. Microservices with defined interfaces and APIs mean that everyone doesn't need to communicate with everyone. Only the people who work on a given microservice need to communicate amongst themselves. Across those groups the communication can be restricted to simply reading documented APIs. That in turn drastically lowers the amount of communication needed.
- gls2ro 6y ago
  > Microservices with defined interfaces and APIs mean that everyone doesn't need to communicate with everyone. This will be true if every team handling their own microservice will treat documentation like a real API like product and make it understandable, concise with clear examples. Also it needs a proper way to accept/debate bug/feature requests. But in my experience this is not happening. There is documentation but it is usually auto generated and most of the times out of date. So instead of reading it and trying to figure it out oneself it is more simpler to just contact the developer thus => more time spent in communication. The same when I need a new feature from their API I setup a meeting as usually sending an email or creating a ticket does not guarantee a response => so more communication.
z3t4 6y ago
You can automate the communication by writing good documentation and api reference with examples.

eloff 6y ago

> Microservices, of course, exasperate this by actually increasing the communication required to make software. I HATE microservices. I've never seen them used appropriately, although I imagine it can be done. But I think if you increase human communication by using microservices you're defeating the raison d'etre of microservices. That's not the fault of microservices - it's the fault of the humans using them badly or where they shouldn't. Story time. I once contracted to a fortune 500 doing a $100M total rewrite with literally 100 microservices all in their own git repo. It was such a disaster I contemplated shorting their stock. I don't know how the story ended, but I feel confident it didn't end well.

TheCoelacanth 6y ago
Microservices can be okay, but they are greatly overused. They are a solution for very large organizations with a ton of teams. For 100 micro-services to make any sense at all, you need to have at least 200-300 developers. Total rewrites, on the other hand, are never anything other than a complete and unmitigated disaster. The only way that you can possibly make a $100M rewrite successful is to do it Ship of Theseus style, where the rewritten code is incorporated into the working and actively-used production software long before the full rewrite is complete. Even then, the full rewrite usually won't complete, so you need to make sure that project is still useful even if you only do a partial rewrite.
- TwoBit 6y ago
  Has there ever been a large scale successful rewrite? How much of Netscape/Firefox was rewritten from the ground up?
- eloff 6y ago
  Full rewrites are usually almost always a disaster. I should know, I've done a few on side projects. This case was a dramatic example of that. > For 100 micro-services to make any sense at all, you need to have at least 200-300 developers. Yeah, at minimum. I think these guys were running at least 2 microservices per developer. That made no sense to me.
- justin_oaks 6y ago
  I've heard of the "Ship of Theseus" rewrites as a recommendation for "evolution, not revolution". I agreed that the big rewrite (i.e. "revolution") is usually a disaster.

dalbasal 6y ago

Yet... the economics of software is such that software companies balloon in size. Software companies/teams/applications of today are many time larger than in 1975. It may be more efficient to have software that's federated and developed by small teams but... Facebook's revenue is $90bn. A social network 10% FB's "size" will make much less than $9bn in ad revenues^. That means that product teams grow until the point Fred Brooks warned about play out... until the marginal team members' contribution is negative. ^For example, Reddit has 10%-20% facebook's users, but only about 2% of its revenue.

marcinzm 6y ago

>Microservices, of course, exasperate this by actually increasing the communication required to make software. I'd argue the exact opposite. Microservices with defined interfaces and APIs mean that everyone doesn't need to communicate with everyone. Only the people who work on a given microservice need to communicate amongst themselves. Across those groups the communication can be restricted to simply reading documented APIs. That in turn drastically lowers the amount of communication needed.

gls2ro 6y ago
> Microservices with defined interfaces and APIs mean that everyone doesn't need to communicate with everyone. This will be true if every team handling their own microservice will treat documentation like a real API like product and make it understandable, concise with clear examples. Also it needs a proper way to accept/debate bug/feature requests. But in my experience this is not happening. There is documentation but it is usually auto generated and most of the times out of date. So instead of reading it and trying to figure it out oneself it is more simpler to just contact the developer thus => more time spent in communication. The same when I need a new feature from their API I setup a meeting as usually sending an email or creating a ticket does not guarantee a response => so more communication.

z3t4 6y ago

You can automate the communication by writing good documentation and api reference with examples.