Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How 'DevOps' Is Killing The Developer

jeffknupp.com

Post reply on HN
Print view View original

161–170 of 219 posts

Re: How 'DevOps' Is Killing The Developer

#161

Post by vacri »

dvanduzer wrote: post #126
mellery451 wrote: post #88

Earlier quoted context omitted.

well, in many places DevOps is implemented as "developers on PagerDuty". When I (the developer) have to be on-call for 7 day rotations, phone by bedside, paged at all hours, then I'm most definitely acting as operations - probably NOT what I signed up for. And, contrary to the stated intentions, I've directly observed developers making crappy, band-aid fixes to ongoing production problems in the interest of "making t…

Giving everyone pager duty can lead to higher quality solutions. The band-aid fixes crop up when ownership of a whole system eventually spreads too thinly. Within the right framework, keeping everyone on pager rotation can lead to much smoother operations, because everyone stays familiar with the system as a whole. This was going around recently, and captures the essence of the philosophy: http://catenary.wordpress.c…

In my experience, it also leads to better solutions because devs who don't get woken by issues with their own code are people who don't particularly care about such faults. I've done on-call before where I've begged the devs to fix issues because they were waking me up needlessly. The devs were nice, but somewhat lazy, and my fix wasn't on their radar. Stick them on on-call, and all of a sudden it's more important to fix.

At one place I worked we had a two-person support shop. We would claim time and again that this or that affected customers or made support hard. The devs would pick and choose what was fun to work on. I ended up leaving and the other guy went on a prearranged month-long vacation. Everyone else had to pick up support (~5 devs) for a month, and I'm told that they had so much trouble with the normal support load that development actually stopped for that month. Apparently when the other guy got back, they started listening a bit more to his concerns, having had a taste of what happens on the pointy end.

In a similar vein, there's a wine distributor where all employees spend their first week half on the phones and half in the packing department, to give everyone a feel of what the core function is and what customers complain about. The guy telling me said that everyone gets the treatment, except the new CEO, who got away with only doing a day rather than a whole week.

Re: How 'DevOps' Is Killing The Developer

#162

Post by k__ »

NickPollard wrote: post #18

DevOps isn't amount making Developers be Ops guys. It's about the fact that automation eats everything, and a significant part of 'ops' is now coding. A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development. It's not about start ups vs Enterprise, it's about 1 person writing programs or 5 people doing things by hand.

To me it always seemed like DevOps is about Devs who do Ops.

Like, I could use an Op for my stuff, but I also could automate "him" away.

When I was studying CS, there were a bunch of people, who didn't like to code, so they became Ops.

If Ops is now about programming, they can't even resort to this branch of CS...

Re: How 'DevOps' Is Killing The Developer

#163

Post by MartinCron »

mjm1138 wrote: post #118
NickPollard wrote: post #18

DevOps isn't amount making Developers be Ops guys. It's about the fact that automation eats everything, and a significant part of 'ops' is now coding. A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development. It's not about start ups vs Enterprise, it's about 1 person writing programs or 5 people doing things by hand.

Actually finally created a Hacker News account to come here and say something similar to this. The article is remarkably misguided in several ways, including a fundamental misunderstanding of what "DevOps" means. Being an SA, what rankles me most is the attitude (unfortunately common in the industry) that "As a developer, I could naturally be the world's greatest Sysadmin, if only it weren't such a waste of my amazin…

I have a somewhat different mindset. "As a developer, I am a demonstrably capable sysadmin, but the organization's discrete silos have made it impossible for me to contribute to ops"

Re: How 'DevOps' Is Killing The Developer

#164

Post by jlawer »

keypusher wrote: post #131
Aqueous wrote: post #128

Earlier quoted context omitted.

Right - and I guess the point is that the person who is working on features ends up also being that one person who does the automatic provisioning and testing pipeline administration work, as well. This is honestly why I've gone with PaaS - mostly Heroku - for several months now when deploying a new application. Why on Earth developers do anything other than working on the core features of their program I don't know.…

Try convincing the ops at a large bank, insurance company or government that they can run their infrastructure in the public cloud, and watch as you get laughed out of the building.

In Australia gov (state & Federal) is now "Cloud First".

Re: How 'DevOps' Is Killing The Developer

#165

Post by agersant »

erkkie wrote: post #50
jimmaswell wrote: post #24

Earlier quoted context omitted.

I hope I'm not actually expected to know what any of those is.

If you're a developer and want to stay relevant I suggest you read up. With distributed systems becoming the norm rather than the exception, developers will need to understand how and where their code runs in production (and how it gets there) to be able to debug issues or write better behaving code.

This may be a simple oversight and I hope I don't sound too pedantic but you may need to broaden your definition of developer a bit. Developers who work on OS, games, embarked systems or professional applications (think CAD) are not very likely to need these anytime soon. More knowledge is always good so I'll check some out anyway!

Re: How 'DevOps' Is Killing The Developer

#166

Post by vinceguidry »

dllthomas wrote: post #140
dvanduzer wrote: post #130

Earlier quoted context omitted.

Whether it's detected at compile time or runtime, a statement that evaluates to DIVBYZERO can be handled. Taking the result as an ordinary value that blows up your program, on the other hand...

"All languages" was a bit tongue in cheek, but even in Haskell, (div 1 0) gives a run-time failure.

In this case, a 'run-time failure' would be completely unacceptable, as the 'run-time' environment is your $X000 hardware manufacturing run. Hardware development isn't in the same league as software. It's not even the same sport. Like comparing football to rugby. Both played on a gridiron, but entirely differently.

Re: How 'DevOps' Is Killing The Developer

#167

Post by cparedes »

IMO, Amazon gets 'DevOps' right. It's mostly just called 'ownership' over in Amazon. (source: I used to work in Amazon as a systems engineer)

You still have specializations - SDE's, systems engineers, DBA's, etc. However, if you write code and it ends up in production, you are responsible for the proper function of that code in production. As a friend of mine put it in terms of developers who don't want to be on-call: 'what, you don't trust the quality of your code?'

DevOps is simply a nicer way of just saying, "own your damn code." The corollary to this is that the organization must help you in getting to that state where you can effectively own your code - this means collaboration (so that you build maintainable systems) and building tools that enable fairly frictionless code ownership.

Re: How 'DevOps' Is Killing The Developer

#168

Post by ErrantX »

zenbowman wrote: post #121
forgottenpass wrote: post #67

Earlier quoted context omitted.

Was (Unix) ops ever not coding? I honestly don't know, I haven't been around that long. But all the old guys I know were "perl is unix duct tape" ops guys. The older, more foundational problems were getting automated back then. Now that they're solved problems, and combined with more and more people running large and/or virtual infrastructure, a new problem domain exists around spinning up machines and deployment. Th…

Yeah, I was never aware of a sysadmin who couldn't code. Generally, a sysadmin has slightly different skills from a developer - they might code in a highly imperative style and always keeping the actual machine/system being targeted in mind, but I've never known a half-decent sysadmin who cannot write code.

Agreed. In my experience a senior sysadmin can work as a above-passable developer. But a senior developer can rarely function as a sysadmin.

As to DBA; I can't help but feeling that the OP hasn't worked with "real" DBA's. That's a whole different ballpark and I've yet to meet a sysadmin or developer who can make even a passable DBA.

I've always thought the hierarchy goes: DBA -> Ops -> Developers. With the last two really about equals.

Re: How 'DevOps' Is Killing The Developer

#169

Post by [deleted] »

vinceguidry wrote: post #166
dllthomas wrote: post #140

Earlier quoted context omitted.

"All languages" was a bit tongue in cheek, but even in Haskell, (div 1 0) gives a run-time failure.

In this case, a 'run-time failure' would be completely unacceptable, as the 'run-time' environment is your $X000 hardware manufacturing run. Hardware development isn't in the same league as software. It's not even the same sport. Like comparing football to rugby. Both played on a gridiron, but entirely differently.

[deleted]

Re: How 'DevOps' Is Killing The Developer

#170

Post by dllthomas »

vinceguidry wrote: post #166
dllthomas wrote: post #140

Earlier quoted context omitted.

"All languages" was a bit tongue in cheek, but even in Haskell, (div 1 0) gives a run-time failure.

In this case, a 'run-time failure' would be completely unacceptable, as the 'run-time' environment is your $X000 hardware manufacturing run. Hardware development isn't in the same league as software. It's not even the same sport. Like comparing football to rugby. Both played on a gridiron, but entirely differently.

First, there exist software environments where errors cost significantly more than a hardware run. Obviously, those environments contain hardware as well, but "cost of a runtime error" is clearly not the only important thing here.

Second, my only point was that the example given was a piss poor example of the difference between hardware and software. Obviously a bad example doesn't disprove the claim it's supposed to support.

Post reply on HN