4 ms·

What does this even mean? The previous poster is basically saying "they screwed it up last time in 6 months, they'll screw it up again". Microservices don't h

What does this even mean? The previous poster is basically saying "they screwed it up last time in 6 months, they'll screw it up again". Microservices don't help. If they couldn't properly design their code without micro-services, throwing docker and micro-services in the mix won't make it magically better. It'll add massive amounts of complexity right off the bat. They'll still be bad coders and bad architects. They still won't know how to lay out their code. Having to split up their code will probably make a bad situation even worse. They'll put the wrong methods on the wrong microservices, and share some 'key' code that shouldn't be shared as the method's on the wrong microservice, or worse still, cut and paste code and have it decay at different rates. They'll create new services that should actually be on an existing service and then gradually they code will duplicate, but with random subtle bugs. The code debt won't disappear, it'll accelerate until they have a bunch of services they daren't touch and one of those services will become "the monolith" and eventually no-one's allowed to deploy to it or the whole thing will come falling down. And all you're saying is "daylight". What does "daylight" mean? The very idea that micro-services will remain 'isolated' in a bad coding team is utterly deluded.

pavel_lishin 10y ago
Imagine a single monolithic jar file, that contains all of the code that lives on any given Docker instance, that decides which services and API endpoints to expose based on poking and prodding environmental variables.
calinet6 10y ago
It's not microservices that help. It's changing the culture around how things are developed and understood, and the parent poster is saying that exposing the team to daylight using something such as an architecture like microservices (or another "good practice") can help push the team toward a better understanding of what a good codebase and stable state should look like. Stop thinking about the specific buzzword hyped up trendy term you're stuck on here; start thinking about the psychological factors that caused the situation in the first place, the environmental pressures that resulted in poor decisions, and the ways you can teach the team—by doing—how to create better applications. Also: > They'll still be bad coders Most often that's not the root cause. Most often the root cause is poor management and poor leadership causing otherwise decent programmers with decent instincts to make decisions against the best interest of themselves and the company. The most common classic debt generation situation is trading off long-term quality for short-term speed and functionality. That is not "bad coders" at work; it's bad managers.
- chupy 10y ago
  I am not a manager and though I agree that sometimes there can be issues with managers/leadership I am really curious why you are defending coders."Coders" that actually do not try to improve themselves and read up on good practices and need managers to actually impose those practices are not really decent coders.
  - calinet6 10y ago
    I'm not defending coders, I'm rejecting the individual mentality—that people are just good or bad by nature, and aren't in some (large) sense a product of their environment as well. Attribution bias tells us that we tend to see behavior as more a product of individual traits than the system that produced it. The system is more responsible than we interpret in almost every case.
andrewmcwatters 10y ago
I almost never see comments like this on HN, because everyone prefers these cryptic, pretentious responses. Surprised this wasn't downvoted.
- hinkley 10y ago
  | cryptic, pretentious response :(
- karmelapple 10y ago
  I really didn't feel it was cryptic or pretentious. However, if you do, can you help describe what made it difficult for you to understand? The daylight word worked great for me, since the idea is to have everyone be able to see what's happening when they introduce changes. If there's just one staging / integration environment where people are building things and patching over one another, and your local environment maybe has deviated a lot from either the staging, production, or even a clean local env, then there's all kinds of unexpected problems that might happen. Getting more things, including your environment, under version control and requiring people to deploy things via files that live in version control rather than a smattering of deployment or env setup commands that not all of the team has visibility into, helps the entire development process go more smoothly.
hinkley 10y ago
The 'daylight' line is me butchering a quote from Louis Brandeis about transparency, 'sunlight is said to be the best of disinfectants' commonly rendered as 'sunlight is the best disinfectant'. That's what I get for posting from mobile. I'm neutral on microservices, pro Docker. What I'm properly alergic to is arcane setups where it's easier for everyone to share a server than it is for anybody to set up a copy of the system that is theirs and theirs alone. In a big enough shop, running all of the microservices you need on your dev box might be possible while running the whole system isn't, because you run out of memory before everything loads. The bad coders often continue to be bad coders because nobody can 'prove' that it's their fault and so they keep dazzling the managers with bullshit and implying that you are the one with the problem, not them. Isolated, repeatable systems means you have to look at how crazy your architecture is instead of ignoring it, and regarding this conversation, there's a paper trail backing up your version of the story. When people don't know which solution is better, they tend to back the side that has more trustworthy people on it, where trustworthy is "doesn't make messes, or helps clean them up when they do". If you make it clear who's the problem and the project management still doesn't intervene, take your skills elsewhere. You're quitting with cause and many managers will value your commitment to sanity.

pavel_lishin 10y ago

Imagine a single monolithic jar file, that contains all of the code that lives on any given Docker instance, that decides which services and API endpoints to expose based on poking and prodding environmental variables.

calinet6 10y ago

It's not microservices that help. It's changing the culture around how things are developed and understood, and the parent poster is saying that exposing the team to daylight using something such as an architecture like microservices (or another "good practice") can help push the team toward a better understanding of what a good codebase and stable state should look like. Stop thinking about the specific buzzword hyped up trendy term you're stuck on here; start thinking about the psychological factors that caused the situation in the first place, the environmental pressures that resulted in poor decisions, and the ways you can teach the team—by doing—how to create better applications. Also: > They'll still be bad coders Most often that's not the root cause. Most often the root cause is poor management and poor leadership causing otherwise decent programmers with decent instincts to make decisions against the best interest of themselves and the company. The most common classic debt generation situation is trading off long-term quality for short-term speed and functionality. That is not "bad coders" at work; it's bad managers.

chupy 10y ago
I am not a manager and though I agree that sometimes there can be issues with managers/leadership I am really curious why you are defending coders."Coders" that actually do not try to improve themselves and read up on good practices and need managers to actually impose those practices are not really decent coders.
- calinet6 10y ago
  I'm not defending coders, I'm rejecting the individual mentality—that people are just good or bad by nature, and aren't in some (large) sense a product of their environment as well. Attribution bias tells us that we tend to see behavior as more a product of individual traits than the system that produced it. The system is more responsible than we interpret in almost every case.

andrewmcwatters 10y ago

I almost never see comments like this on HN, because everyone prefers these cryptic, pretentious responses. Surprised this wasn't downvoted.

hinkley 10y ago
| cryptic, pretentious response :(
karmelapple 10y ago
I really didn't feel it was cryptic or pretentious. However, if you do, can you help describe what made it difficult for you to understand? The daylight word worked great for me, since the idea is to have everyone be able to see what's happening when they introduce changes. If there's just one staging / integration environment where people are building things and patching over one another, and your local environment maybe has deviated a lot from either the staging, production, or even a clean local env, then there's all kinds of unexpected problems that might happen. Getting more things, including your environment, under version control and requiring people to deploy things via files that live in version control rather than a smattering of deployment or env setup commands that not all of the team has visibility into, helps the entire development process go more smoothly.

hinkley 10y ago

The 'daylight' line is me butchering a quote from Louis Brandeis about transparency, 'sunlight is said to be the best of disinfectants' commonly rendered as 'sunlight is the best disinfectant'. That's what I get for posting from mobile. I'm neutral on microservices, pro Docker. What I'm properly alergic to is arcane setups where it's easier for everyone to share a server than it is for anybody to set up a copy of the system that is theirs and theirs alone. In a big enough shop, running all of the microservices you need on your dev box might be possible while running the whole system isn't, because you run out of memory before everything loads. The bad coders often continue to be bad coders because nobody can 'prove' that it's their fault and so they keep dazzling the managers with bullshit and implying that you are the one with the problem, not them. Isolated, repeatable systems means you have to look at how crazy your architecture is instead of ignoring it, and regarding this conversation, there's a paper trail backing up your version of the story. When people don't know which solution is better, they tend to back the side that has more trustworthy people on it, where trustworthy is "doesn't make messes, or helps clean them up when they do". If you make it clear who's the problem and the project management still doesn't intervene, take your skills elsewhere. You're quitting with cause and many managers will value your commitment to sanity.