4 ms·

1. I think this is rather obvious, work with what you have. Maybe think about hiring specifically for areas your team is in lacking in, as long as the team as a

1. I think this is rather obvious, work with what you have. Maybe think about hiring specifically for areas your team is in lacking in, as long as the team as a whole will see decent benefit from it. 2. I hate to say you're doing microservices "wrong" but I'd really question project structure and practices being the culprit behind the cost of doing devops with microservices. 3. This seems like an engineering fault, rather than some implicit principle behind those concepts causing more downtime. 4. How is CI a plaster on the problem of microservices? CI is useful with or without microservices. 5. Agile was always meant to be a guideline, not an end all and be all. It's meant to get your team to figure out how it wants to work, and write code before process. See: http://agilemanifesto.org/ http://agilemanifesto.org/ The problems you are describing seem like big problems with your team, engineering and management. No amount of process and technology is ever going to fix a dysfunctional (sorry if that's too blunt) team. What I get from this, instead of having processes in place that make it easy to move code out, you're removing tooling to slow things down intentionally with the superficial result of "stabilizing" the entire development effort. The solution appears to be to get your team to write less code, and force management to bow down to the new reality of these "stabilizing" changes. Both of which can and sometimes should be done regardless of processes and tooling in place. The best code is the code you don't write. But don't blame the tooling on making it easy for a team to be lazy and remove the all important characteristic of a team self-critiquing (i.e, "Do we really need this feature", "That'd be nice to have but right now we're managing to get things done.", "Did I actually test my code, was it reviewed, or am I just counting on the fact that I can shove something else out later while our redundancy systems pick up the slack?")

mhluongo 10y ago
Quite a few of these issues are common in other orgs. "You're doing it wrong" isn't great advice :/
- justinlaster 10y ago
  I would say in a lot of cases understanding that there are some basic failures is probably a great starting point to cleaning up the development effort. There's not much else I can say other than that, considering how vague OP's post is. "Good" engineers will get things done and use common tooling to their advantage. This requires actually understanding the principle behind the tools, not just shoving things in and hoping it all magically works. If you have a lot of "good" practices that are supposed to make it easy to move code around and you find that things just keep breaking, one could reasonably assume that it's simply highlighting an underlying issue. I'd start figuring out which engineers (and management) is causing more work for our organization than they're putting out. What I think we're seeing from OP is lot of "in name only" practices.
  - mhluongo 10y ago
    Some good practices aren't a good fit for a particular organization. Moving the discussion to whether your engineers are "good", rather than whether they understand the organization's needs, is reductive. If you want to develop better practices in an industry, saying the practitioner should be "good" isn't very helpful. Of course they should be good! But unfortunately, despite the trope, we can't all hire the best, and part of the reason we have best practices is to work well without only hiring the top 1% of engineers. An example from my experience (mentioned in another comment)- microservices are a good practice in many larger orgs, because a big piece of what they solve is political- but the overhead of running a distributed system at a small org often isn't worth it.
    - justinlaster 10y ago
      I put "good" in quotes for a reason. I never said "hire the best"; that isn't a requirement for anything that was stated. There shouldn't really be a measurable overhead of running a distributed system, at least in the context of microservices. I strongly disagree with the sentiment that a distributed system isn't "worth it" at smaller organizations. I'm part of one, and it helps keep things flexible while increasing reliability of the "overall" system(s). But that's neither here nor there. One shoe size won't fit everyone, but OP ran down a gambit of things and seemed to have issue with each one. It is exceedingly unlikely they are doing anything eccentric enough to the point of proclaiming CI is just a bandaid on the broken concept of microservices. I will contend that the source of OP's insights are... misappointed, and by breaking down efficiencies and flexibility they're merely masking certain underlying problems. What's more probable? An organization hired some wrong people, or a generic list of strongly supported practices over the course of two to three decades are to blame for an organization's failings? I guess that's my take on it.

mhluongo 10y ago

Quite a few of these issues are common in other orgs. "You're doing it wrong" isn't great advice :/

justinlaster 10y ago
I would say in a lot of cases understanding that there are some basic failures is probably a great starting point to cleaning up the development effort. There's not much else I can say other than that, considering how vague OP's post is. "Good" engineers will get things done and use common tooling to their advantage. This requires actually understanding the principle behind the tools, not just shoving things in and hoping it all magically works. If you have a lot of "good" practices that are supposed to make it easy to move code around and you find that things just keep breaking, one could reasonably assume that it's simply highlighting an underlying issue. I'd start figuring out which engineers (and management) is causing more work for our organization than they're putting out. What I think we're seeing from OP is lot of "in name only" practices.
- mhluongo 10y ago
  Some good practices aren't a good fit for a particular organization. Moving the discussion to whether your engineers are "good", rather than whether they understand the organization's needs, is reductive. If you want to develop better practices in an industry, saying the practitioner should be "good" isn't very helpful. Of course they should be good! But unfortunately, despite the trope, we can't all hire the best, and part of the reason we have best practices is to work well without only hiring the top 1% of engineers. An example from my experience (mentioned in another comment)- microservices are a good practice in many larger orgs, because a big piece of what they solve is political- but the overhead of running a distributed system at a small org often isn't worth it.
  - justinlaster 10y ago
    I put "good" in quotes for a reason. I never said "hire the best"; that isn't a requirement for anything that was stated. There shouldn't really be a measurable overhead of running a distributed system, at least in the context of microservices. I strongly disagree with the sentiment that a distributed system isn't "worth it" at smaller organizations. I'm part of one, and it helps keep things flexible while increasing reliability of the "overall" system(s). But that's neither here nor there. One shoe size won't fit everyone, but OP ran down a gambit of things and seemed to have issue with each one. It is exceedingly unlikely they are doing anything eccentric enough to the point of proclaiming CI is just a bandaid on the broken concept of microservices. I will contend that the source of OP's insights are... misappointed, and by breaking down efficiencies and flexibility they're merely masking certain underlying problems. What's more probable? An organization hired some wrong people, or a generic list of strongly supported practices over the course of two to three decades are to blame for an organization's failings? I guess that's my take on it.