It’s easy to pretend that, like say, HR, because you don’t see the work that’s being done, no work is actually being done, and you could do a better job if you’d had the job from the beginning.
However, how often do you get to do greenfield work as a developer?
Right, now imagine you’re not even writing code, just pushing configuration around. OPs is often a constraint satisfaction problem, not an engineering problem.
Developers can come along and whip up a quick ldap/logging/monitoring/pipeline, but when it gets to the long tail of the hundreds of hours of standard practice (ie. you have to write documentation for that thing you wrote) and additional tooling (yes, you do need to write custom integration to active directory because of [corporate policy here]...) it’s a big mess, badly done, by developers who didn’t really want to in the first place, and don’t want to maintain it (and sure as hell not out of hours when it goes down).
TLDR; don’t be ridiculous. Smart people do this stuff professionally and then you come along and think you’re some hot shot who can do it in a few minutes?
Get off your high horse. You have a domain skill set that doesn’t include competence in the domain you superficially think you could easily do.
Try listening to why people say it takes a long time, and work within the constraints of the domain, or you will produce substandard outcomes.
I’ve seen it in so many places, it makes me just sigh now. As a developer (which I am), my complaint with ”Devops” is that management has been given the same expectation you just articulated.
ie. that ops is basically people who were never good enough to be programmers, and basically, despite years of training and experience, are basically incompetent and not “agile”.
...and somehow, developers, with no training in the domain, will just do a better job of it.
They don’t. In any of the places I’ve worked and seen it tried, in like, the last ten years.
Ymmv.
only build for the next scale factor.
Basically, yes. Mainly because I do this professionally too.
Just because I haven’t been assigned to do it this time does not mean I can’t.
How about you are generous and interpret my comment as if I know what I’m talking about, then I won’t be an ass and nuance my previous statement a bit.
Something can (and probably should) take a month the first time around. Then, if you’ve actually fulfilled your promise as ‘devops’ any second time you are doing this thing it should take significantly less time. Maybe you’ve not automated all parts, but certainly the most common ones.
I think we’re now at iteration 20+, and it still takes a month for every new environment (dev, sqa, prod) of the same application.
Now it’s definitely possible there is a reasonable explanation for that, but it’s starting to get a bit suspect. Enough so that I’ll make a frustrated comment about it on HN when the subject comes up.
It could be a matter of work in progress or internal bottlenecks.
[0] has a good summary of WIP after the heading titled "Why Do We Need To Visualize IT Work And Control WIP?".
TLDR - read the Phoenix Project.
[0] https://itrevolution.com/resource-guide-for-the-phoenix-proj...
Mainly because ops cannot be bothered to.
Telling me something is going to take a month when it should take only a few minutes if you’d done your job right the first time means I’m going to be doing substandard operations work.
But if that’s the case, is it really sub-standard?