It is as another author wrote: It is a people problem. We programmers like the "do one thing" mantra so we tend to want to add it everywhere - even in places were the cost may outweigh the benefits.
It's not microservice or monolith; it's cognitive load
151–160 of 195 posts
Re: It's not microservice or monolith; it's cognitive load
#152Earlier quoted context omitted.
The entire purpose of microservices is to comply with Conway.
This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.
Re: It's not microservice or monolith; it's cognitive load
#153Earlier quoted context omitted.
Usually, when you put quotes around something, it's considered proper to actually be quoting someone instead of trying your best to make them sound like a clown. But, why don't I go ahead and give you a real quote. Of our 400+ repos, 100 or so of them are deploy projects. The only time they need to change in batch is if one of our boilerplate scripts changes. This is infrequent, but when it does happen, we have a "pr…
Someone got to say it so I will. Most of your comments comes across like you've gone off the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. I really hope your colleagues are onboard with…
Where did I say that, exactly? I’ve said nothing about intellect. I’ve mentioned tacit knowledge multiple times, because I have enough experience to recognize how ludicrous a lot of this sounds. It sounded that way to me at first until I experienced it and saw the pieces fit together. That’s how tacit knowledge works, especially when it is counter to average knowledge. It’s the same reason American industry smashed Japanese cars in demonstration instead of listening to them when they said large batches were bad (I’m simplifying here somewhat)
And which part, specifically sounds incompetent? I’m happy to discuss that.
By the way, it's decidedly difficult to challenge a common belief, dare I say, orthodoxy, without sounding insane, confident, or even cocky. Could I be better at it? Of course, and I work at it, but I also am not here to make friends. I'm here to provide a perspective that I believe is sorely lacking from the development community and is drowned out by the orthodoxy, its acolytes, and its beneficiaries.
> I really hope your colleagues are onboard with this and that this isn't your own dogmatic crusade dragging them along.
Given their tenure on the team and their other options, it’s a pretty safe bet. It’s not my crusade, btw, it’s our teams goal to manage a relatively complex project with a relatively small team.
Also, someone has to say it, so I will. You have now dropped this conversation, which was about the work, into ad hominem and straw man attacks. That’s one of the worst part about this industry: people’s inability to debate and discuss without attacking people or glorifying celebrities.
Re: It's not microservice or monolith; it's cognitive load
#154Earlier quoted context omitted.
Someone got to say it so I will. Most of your comments comes across like you've gone off the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. I really hope your colleagues are onboard with…
> Someone got to say it so I will. Most of your comments comes across like you've gone of the rails and started replacing competency, not to mention humility, with narcissism. Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag that I'm not surprised people interpret it as satire. Where did I say that, exactly? I’ve said nothi…
Let's see here:
> You have experienced what happens when web developers cosplay as software architects.
> That is, you experienced an average team doing average work misguided by average bad advice. It says absolutely nothing about software design. It only speaks to the fat part of the bell curve doing what it always does.
> because, unlike them, I have significant material experience in both camps.
> It’s hard to imagine worse advice.
> But please, by all means, continue to spread disinformation and keep us in the dark ages.
> Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.
That sets a good friendly tone huh? If you can't take push back, don't be an arse to begin with.
> And which part, specifically sounds incompetent? I’m happy to discuss that.
Your arrogance precludes a fruitful discussion. But I believe that this needs to be called out, if nothing else to nudge other people to also do it when they see it, or to, albeit much less likely, nudge you towards eating some humble pie.
Re: It's not microservice or monolith; it's cognitive load
#155I totally agree... the real question is how to reduce cognitive load. Try to get a system that can fit in your head, although I have totally failed to achieve this myself. But it is a goal!
Create self-contained frameworks and libraries by extracting code that starts becoming heavy and could be useful by its own. These are the useful abstractions. Constantly seek to specify, document, and simplify the protocols you implement. The clearer the ideas, the cleaner the implementation. Strive to use a single programming language. Organize your code like you would organize a city or a book.
Re: It's not microservice or monolith; it's cognitive load
#156Earlier quoted context omitted.
How do you know that? Hint: you don’t. You’re not the first to tell us what we do is impossible, and you won’t be the last. By the way, I know how it sounds. And I know why a person would fear it. And, I know why they’d be incorrect in their assessment, because, unlike them, I have significant material experience in both camps.
This whole business has had few conceptual ideas that stand apart from fashion and stood the tests of time. A lot of people look down on C now for various reasons, but it's still extremely useful and going strong 50+ years later. Even though I'm older than C itself in the last year or two using it intensively, I found new insights in how to arrange things and what to avoid to make things more robust and maintainable.…
Re: It's not microservice or monolith; it's cognitive load
#157Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordinat…
If you don't get something, perhaps it's that this is a bit of a holy war, and as with all holy wars, each camp tends to argue things from a very black-and-white perspective. As with most things, though, the truth is not so binary.
Re: It's not microservice or monolith; it's cognitive load
#158Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordinat…
I often have had the feeling that people tend to try to solve code-organisation issues with microservices. Sure you can code a tangled mess in a monolith, but adding TCP connections and Kubernetes to the problems you have probably won't make things better. Instead, rewriting some code to use whatever applicable design pattern probably will make it better. An analogy that comes to mind is looking for a new house. Most…
Yes!
I call this "moving the spaghetti". That tangled mess in a monolith can easily be (and often is) replaced with an equally tangled mess in microservices. It's just that the mess will be in the connections between services rather than in the code itself.
I see the same thing in certain OOP camps -- removing the spaghetti code from the actual lines of code into the inheritance hierarchy instead.
It's much like sweeping the floor and leaving the dirt under the carpet. At first glance, it looks cleaner. But if you have to move the carpet, you see the truth.
Re: It's not microservice or monolith; it's cognitive load
#159Earlier quoted context omitted.
This whole business has had few conceptual ideas that stand apart from fashion and stood the tests of time. A lot of people look down on C now for various reasons, but it's still extremely useful and going strong 50+ years later. Even though I'm older than C itself in the last year or two using it intensively, I found new insights in how to arrange things and what to avoid to make things more robust and maintainable.…
Do you know what does stand the test of time? Design principles that are based on the immutable laws of physics. There's a reason that I can quote Plato to support the notion of partitioning. There's a reason that the basic principles are used in the design of every single significant thing in the world. There's a reason Linux has as many modules as it has (for them, a single monorepo works, but multiple works too --…
Re: It's not microservice or monolith; it's cognitive load
#160Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all. Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that. The principled approach is really to simply not do that, for the basic latency costs. I mean,…
Maybe WoW didn't run on Microservices, but you can bet the project was divided into a bunch of different fiefdoms. Just they were separated at the interface level rather than the network level. Same concept though. Ultimately if you've got different teams working simultaneously, they should be working on non-conflicting features. Microservice is just one architecture that develops within this constraint. You'll never…
The worst projects I've worked on (including my current one) had components where people "owned" them. They fight against outside input and treat "their" part as a little kingdom that they rule. It's worse in almost every way.
Obviously there are limits - at some point your project is big enough that you have to have some specialist individuals and teams, but it's wise to avoid that as much as possible.