4 ms·

I worked for someone who had mindset that whatever technology developers wanted was always good and ops should just shut up and put up with it because devs are

I worked for someone who had mindset that whatever technology developers wanted was always good and ops should just shut up and put up with it because devs are the ones that make the money for the business. Very infuriating mindset to deal with.

dagw 7y ago
And I've worked at companies where the devs where expected to know their place and not question ops, because ops was seen as the serious adults in the room keeping things running and devs where seen as easily distracted children chasing after the shiniest thing that most recently caught their attention. Made perfect sense when I was on the ops side and was super annoying when I was on the dev side :) Imagine if people could all just get along.
- arethuza 7y ago
  Smaller companies I've worked for don't really seem to suffer from this problem although once companies are larger and have separate teams (and, perhaps more importantly, managers who are incentivized in different ways) this problem always seem to arise.
  - dagw 7y ago
    once companies are larger and have separate teams The real problem always starts when they become separate cost centers with separate budgets and have to independently show a 'profit'.
- throwaway286 7y ago
  Let's make a movement to bridge the fundamental divide between Dev and Ops.. we can call it OpsDev.
  - ConfusedDog 7y ago
    You are forgetting Cybersecurity team. Now, that's a fun party. SecOpsDev.
    - goatinaboat 7y ago
      You jest but a dev chucking an insecurable thing over the fence to ops is very common. I will bet that’s how there are so many open MongoDB’s out there.
- turk73 7y ago
  The place like that where I worked ended up doubling down on AS/400. I laughed out loud and then quit. What a bunch of idiots! I don't know how they are even still in business. Dev cycles were 6-12 mos. Imagine asking for a feature and then getting it on a green screen in 12 months!
- nobleach 7y ago
  Having worked in both DevOps (or Ops as we called it in 2002), there really was a belief that the developers were stupid, and they'd burn the whole place down if we gave them any leeway. As a developer, I've seen DevOps as a frustrating gate at times. The only things I think can fix this divide are communication and built trust. (and probably less assumed malice)
  - zeveb 7y ago
    > Having worked in both DevOps (or Ops as we called it in 2002), there really was a belief that the developers were stupid, and they'd burn the whole place down if we gave them any leeway. I've been on both sides of this divide myself, but have spent the last fifteen years or so as a developer. In my experience, developers will burn the whole place down if we're given the chance. We're focused on writing code, and it's boring to write the same code over and over: we want to write new code, in exciting ways, and we are surprised when it fails in exciting ways. We're focused on delivering features; our incentives are all about getting it done, not about getting it done well (our industry doesn't even have a consistent view of what's good or bad: note that C/C++ are still used in 2019) or supportably. Some organisations really try had to properly incentivise developers, but I've not seen it really work yet. DevOps is an attempt to incentivise developers by getting us to buy into ops. I've read a lot of success stories, but not seen a lot of success with my own eyes. I do my best to be diligent, I do my best to wear my Ops hat — yet I still fall down. I don't think that it's unavoidable, but so far I've not avoided it, and I've not seen others avoid it either.
philpem 7y ago
I've seen this in a 50-person volunteer group. The devs turned up every year with a proposal to throw away and completely rewrite what they'd done the previous year. No incremental upgrades -- a complete rewrite every time. This worked great when several other business systems relied on their vanity toy, and invariably the API would change with every release. There's a balance to be struck between 'never change anything because it's always worked' and 'new shiny every week'. In my experience it's an absolute nightmare getting people to agree where the line is, and on top of that, get management to buy-in and push-back when either side oversteps.

dagw 7y ago

And I've worked at companies where the devs where expected to know their place and not question ops, because ops was seen as the serious adults in the room keeping things running and devs where seen as easily distracted children chasing after the shiniest thing that most recently caught their attention. Made perfect sense when I was on the ops side and was super annoying when I was on the dev side :) Imagine if people could all just get along.

arethuza 7y ago
Smaller companies I've worked for don't really seem to suffer from this problem although once companies are larger and have separate teams (and, perhaps more importantly, managers who are incentivized in different ways) this problem always seem to arise.
- dagw 7y ago
  once companies are larger and have separate teams The real problem always starts when they become separate cost centers with separate budgets and have to independently show a 'profit'.
throwaway286 7y ago
Let's make a movement to bridge the fundamental divide between Dev and Ops.. we can call it OpsDev.
- ConfusedDog 7y ago
  You are forgetting Cybersecurity team. Now, that's a fun party. SecOpsDev.
  - goatinaboat 7y ago
    You jest but a dev chucking an insecurable thing over the fence to ops is very common. I will bet that’s how there are so many open MongoDB’s out there.
turk73 7y ago
The place like that where I worked ended up doubling down on AS/400. I laughed out loud and then quit. What a bunch of idiots! I don't know how they are even still in business. Dev cycles were 6-12 mos. Imagine asking for a feature and then getting it on a green screen in 12 months!
nobleach 7y ago
Having worked in both DevOps (or Ops as we called it in 2002), there really was a belief that the developers were stupid, and they'd burn the whole place down if we gave them any leeway. As a developer, I've seen DevOps as a frustrating gate at times. The only things I think can fix this divide are communication and built trust. (and probably less assumed malice)
- zeveb 7y ago
  > Having worked in both DevOps (or Ops as we called it in 2002), there really was a belief that the developers were stupid, and they'd burn the whole place down if we gave them any leeway. I've been on both sides of this divide myself, but have spent the last fifteen years or so as a developer. In my experience, developers will burn the whole place down if we're given the chance. We're focused on writing code, and it's boring to write the same code over and over: we want to write new code, in exciting ways, and we are surprised when it fails in exciting ways. We're focused on delivering features; our incentives are all about getting it done, not about getting it done well (our industry doesn't even have a consistent view of what's good or bad: note that C/C++ are still used in 2019) or supportably. Some organisations really try had to properly incentivise developers, but I've not seen it really work yet. DevOps is an attempt to incentivise developers by getting us to buy into ops. I've read a lot of success stories, but not seen a lot of success with my own eyes. I do my best to be diligent, I do my best to wear my Ops hat — yet I still fall down. I don't think that it's unavoidable, but so far I've not avoided it, and I've not seen others avoid it either.

philpem 7y ago

I've seen this in a 50-person volunteer group. The devs turned up every year with a proposal to throw away and completely rewrite what they'd done the previous year. No incremental upgrades -- a complete rewrite every time. This worked great when several other business systems relied on their vanity toy, and invariably the API would change with every release. There's a balance to be struck between 'never change anything because it's always worked' and 'new shiny every week'. In my experience it's an absolute nightmare getting people to agree where the line is, and on top of that, get management to buy-in and push-back when either side oversteps.