3 ms·

My advice is favour places with engineers who both have the knowhow and the power to make decisions based on cost/benefit analysis. There is no right or wrong w

by pwm 7y ago

My advice is favour places with engineers who both have the knowhow and the power to make decisions based on cost/benefit analysis. There is no right or wrong without context. Beware of places where engineering is driven by hype and/or dogma.

gridlockd 7y ago
You mean the engineers that have rolled out multiple monoliths and microservice architectures across different teams with different backgrounds, all the while keeping careful track of expenditures? I'm sorry, these people do not exist. People are going to eyeball and wing it, based on personal preference and their gut feeling. Dress that up with good-sounding arguments and maybe even some metrics and you have all you need to convince the stakeholders - who almost certainly don't understand the issue at a deeper level, nor do they care to. It's also made more nuanced by the fact that people talk about different things when they mean "microservice". Anything can be split up into arbitrarily small services. This is attractive from a management standpoint, because you can assign engineers in a simple manner without too much crosstalk. Most likely, nobody will ever bother to check if you're spending 10x the engineering resources to do the job. In essence, I can wholly recommend microservices to engineering managers who want to take full advantage of Parkinson's Law.
collyw 7y ago
> where engineering is driven by hype and/or dogma. That's the whole industry pretty much.
2T1Qka0rEiPr 7y ago
Hah, this also reminds me of a company where we went back on a decision that had been made before I joined, and moved our basket (containing highly normalization, non-transient data) out of MongoDB and back into a SQL one. No one had any idea why Mongo was chosen for the task, but a very likely reason was that it was a period where NoSQL was very much en vogue.

by pwm 7y ago

gridlockd 7y ago

You mean the engineers that have rolled out multiple monoliths and microservice architectures across different teams with different backgrounds, all the while keeping careful track of expenditures? I'm sorry, these people do not exist. People are going to eyeball and wing it, based on personal preference and their gut feeling. Dress that up with good-sounding arguments and maybe even some metrics and you have all you need to convince the stakeholders - who almost certainly don't understand the issue at a deeper level, nor do they care to. It's also made more nuanced by the fact that people talk about different things when they mean "microservice". Anything can be split up into arbitrarily small services. This is attractive from a management standpoint, because you can assign engineers in a simple manner without too much crosstalk. Most likely, nobody will ever bother to check if you're spending 10x the engineering resources to do the job. In essence, I can wholly recommend microservices to engineering managers who want to take full advantage of Parkinson's Law.

collyw 7y ago

> where engineering is driven by hype and/or dogma. That's the whole industry pretty much.

2T1Qka0rEiPr 7y ago

Hah, this also reminds me of a company where we went back on a decision that had been made before I joined, and moved our basket (containing highly normalization, non-transient data) out of MongoDB and back into a SQL one. No one had any idea why Mongo was chosen for the task, but a very likely reason was that it was a period where NoSQL was very much en vogue.