No. But if you are writing software that can't be maintained in production by the team that's doing the maintenance, then you a falling short in a massive part of your job.
There are lots of reasons to have difficulty working with DevOps people, but you really do have to work it out in order to provide the kind of value that your company needs. I have met people that just don't care about that. They are only interested in a fairly selfish pursuit of what they find compelling in programming. I guess one could portray that as being a "diva", but I think it's a lot more complex than that. In any case, there really isn't any room for that kind of thing if the teams wants to be successful. I've worked with people like that before and as the project inevitably dies, they are the first to blame other people. Which is sad because they are often very skillful and will have no trouble finding another group to help crash.
This reads to me like someone who has never seen a project die due to being stymied by unreasonable delays and forced technical constraints coming from devops or central IT, usually for reasons of their own political control or job security. This is why the cycle gets repeated and repeated where you have to break devops rules to innovate in some way that is deeply required by your project, you do so with great maturity towards the security implications, costs, maintainability, etc., of your new tooling, and deliver the whole thing as proof that devops was hindering unnecessarily, thus basically forcing devops to accept your changes, which is a horribly antagonistic way for it all to work, but it just goes on.
The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.
If you build something that DevOps can use, then there is no problem. I can't tell you how to navigate the waters from the start of the project to success -- that's all dependent upon the people involved and requires a fair amount of people skills to do well. On the other hand I've seen enough "convenient for developers, impossible for devops solutions" to know that sometimes developers lack the background to get it right. Couple that with a bit of hubris and you get the classic, "Well, I did my job. It's not my fault that devops are clueless and can't do their job".
I'm not in any way saying that this is what you do. How could I know one way or the other? I'm just saying that it's a pretty common occurrence in my fairly extensive experience (hint: all my hair has been grey for a decade and I still work as a programmer ;-) ).
Thus my answer: No, having problems with DevOps is not being a "diva". Ignoring the problems of DevOps so that you can have things easier for you is an unfortunately common, but none-the-less disastrous approach. Are there teams where DevOps are inflexible at the cost of everybody else involved? Of course, that's common too: hence the "No".
I probably wouldn't say that, but I'd suggest that either you or your ops person could do with learning a bit of empathy and better communicating what problems you're each trying to solve. Someone who actually gets the concept of devops (the collaboration between dev and ops) should be able to articulate why they're asking for particular things to be done, and what benefits will come from it in terms of reliability and being able to analyse issues as they come up.
Unless the ops person on the other side of this conversation is really bad they're unlikely to be asking you to do things just for the sake of it - there'll be a good reason, just as you have your reasons for wanting to do things your way. Devops is all about finding a middle ground between those two places, and improving life for everyone involved.
Comments
Am I a diva if I think DevOps people are getting in my way from doing what I want?
No. But if you are writing software that can't be maintained in production by the team that's doing the maintenance, then you a falling short in a massive part of your job.
There are lots of reasons to have difficulty working with DevOps people, but you really do have to work it out in order to provide the kind of value that your company needs. I have met people that just don't care about that. They are only interested in a fairly selfish pursuit of what they find compelling in programming. I guess one could portray that as being a "diva", but I think it's a lot more complex than that. In any case, there really isn't any room for that kind of thing if the teams wants to be successful. I've worked with people like that before and as the project inevitably dies, they are the first to blame other people. Which is sad because they are often very skillful and will have no trouble finding another group to help crash.
This reads to me like someone who has never seen a project die due to being stymied by unreasonable delays and forced technical constraints coming from devops or central IT, usually for reasons of their own political control or job security. This is why the cycle gets repeated and repeated where you have to break devops rules to innovate in some way that is deeply required by your project, you do so with great maturity towards the security implications, costs, maintainability, etc., of your new tooling, and deliver the whole thing as proof that devops was hindering unnecessarily, thus basically forcing devops to accept your changes, which is a horribly antagonistic way for it all to work, but it just goes on.
The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.
If you build something that DevOps can use, then there is no problem. I can't tell you how to navigate the waters from the start of the project to success -- that's all dependent upon the people involved and requires a fair amount of people skills to do well. On the other hand I've seen enough "convenient for developers, impossible for devops solutions" to know that sometimes developers lack the background to get it right. Couple that with a bit of hubris and you get the classic, "Well, I did my job. It's not my fault that devops are clueless and can't do their job".
I'm not in any way saying that this is what you do. How could I know one way or the other? I'm just saying that it's a pretty common occurrence in my fairly extensive experience (hint: all my hair has been grey for a decade and I still work as a programmer ;-) ).
Thus my answer: No, having problems with DevOps is not being a "diva". Ignoring the problems of DevOps so that you can have things easier for you is an unfortunately common, but none-the-less disastrous approach. Are there teams where DevOps are inflexible at the cost of everybody else involved? Of course, that's common too: hence the "No".
I probably wouldn't say that, but I'd suggest that either you or your ops person could do with learning a bit of empathy and better communicating what problems you're each trying to solve. Someone who actually gets the concept of devops (the collaboration between dev and ops) should be able to articulate why they're asking for particular things to be done, and what benefits will come from it in terms of reliability and being able to analyse issues as they come up.
Unless the ops person on the other side of this conversation is really bad they're unlikely to be asking you to do things just for the sake of it - there'll be a good reason, just as you have your reasons for wanting to do things your way. Devops is all about finding a middle ground between those two places, and improving life for everyone involved.