|
A lot of these things that you're pointing out are pretty vague. To pick apart one: "devops", it can mean "using docker", and/or "continuous deployment of configs", and/or "greater developer empowerment", and/or "no dedicated infrastructure team", etc. IMO, attacking all of "devops" (or "agile", or "cloud computing") at once is not productive, because it means so many things. So if you don't get specific, as others have said, it makes you seem like you just oppose new things. For example with devops, a very rational concern is that if the infrastructure team shrinks or disappears, then there's no one on the hook for making things all work at the same time. If you leave it to the developers of each team to make their thing work, you are likely to have a continually broken development environment. A good argument to oppose any change without a clear rationale for the change occurring is "if it ain't broke don't fix it." This, at least, leads to someone explaining why change is necessary, and then from there perhaps you can have a conversation. |
When you look at it it becomes clear that it is important to understand which levels and definitions of "brokenness" are possible in your case, and even more importantly which of them matter and how much. Only then you can look at each proposed solution to find out which of the important problems it solves and how well.