Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Luckily the industry doesn’t really use this term [OOP] any more so we can ignore the changed meaning.

OOP is still a widely used term today.

> It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”.

That doesn't sound waterfall-y at all.

> If you can hire a “DevOps engineer” to fulfil a specific role on a software team then we have all lost at using the phrase DevOps.

DevOps was never about eliminating all operations roles. It is about better cooperation between dev and ops.

> This one used to mean “psychologist/neuroscientist developing computer models to understand how intelligence works” and now means “an algorithm pushed to production by a programmer who doesn’t understand it”.

No, that's never what it meant. It was always a branch of computer science, going as far back as Alan Turing.[0]

> Previously something very specific used in the context of financial technology development.

Not at all. It was coined by Ward Cunningham[1] who happened to be working on financial software. The metaphor was never meant to be restricted to financial software. The fact he was working on financial software is largely irrelevant other than possibly having given him inspiration for the metaphor.

> Was originally the idea that maybe the things your software does should depend on the things the customers want it to do. Now means automated tests with some particular syntax.

Again, completely wrong. The article that introduced BDD was explicitly about automated testing.[2]

[0] https://en.wikipedia.org/wiki/History_of_artificial_intellig...

[1] http://c2.com/doc/oopsla92.html

[2] https://dannorth.net/introducing-bdd/




> That doesn't sound waterfall-y at all. Sounds like an iterative approach to me.

I think you missed the crux of the issue: in a lot of companies, Agile is definitely waterfall-ish, with a lot of pre-planning, design working a few sprints in advance, a lot of "getting it perfect" during PR reviews, no follow-up, no evaluating the work midway, no admitting failure and reverting it before finished, etc.

> Having roles for operations is not incompatible with DevOps at all.

I think you also missed the problem on this one. If you have "roles for operations" that doesn't involve development, it's not a devops role, it's just an operations role. Sure you can have devops in the mix, but someone doing operations exclusively isn't devops.


> I think you also missed the problem on this one. If you have "roles for operations" that doesn't involve development, it's not a devops role, it's just an operations role. Sure you can have devops in the mix, but someone doing operations exclusively isn't devops.

It seems we both agree that having a DevOps engineer is not incompatible with DevOps?


We don't. "Operations" is not a synonym "DevOps".

Devops does involve operations, but is not exclusively that.

Having an Operations person work together with developers doesn't automatically make the Ops engineer into a DevOps engineer. Just as it wouldn't make the non-operations developers into DevOps engineers.

Maybe the better term would be "Operations Engineer for multi-disciplinary Team". Not DevOps.

EDIT: It was previously written "It seems we both agree that having a Ops engineer is not incompatible with DevOps?"


I feel like you misunderstood me. I wasn't arguing about the definition of a "DevOps engineer". Since the author didn't give one, I went by the charity principle and used a definition that would make their argument stronger (a DevOps engineer that really is just an operations engineer). But even with that definition, having an operations engineer on a team does not preclude it from practicing DevOps and is arguably in line with the DevOps practice of increasing collaboration between dev and ops.


The point of the article is that even if we go by your interpretation where "a DevOps engineer that really is just an operations engineer", then we can completely retire the term, since it's not really special and we can just keep using "Operations". The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of.

Moreover, in a lot of places there are "DevOps" teams that consist only of Operations people, which is even worse. The usage of DevOps is to attract candidates, not to differentiate the skillset needed.


> The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of.

Do you mean that a DevOps engineer's role and skillset is different from an operations engineer? And that hiring DevOps engineers instead of operations engineers is more in line with DevOps?


If we go by the original usage of the term, then yes, it's different skillsets between Ops and DevOps. You can't announce an Ops position with a DevOps title since the two are different by definition.

However, even if we go by your definition that it is the same thing, then the "Dev" part is completely redundant and we should just call it "Ops", since it's by definition the same thing and it doesn't warrant a new title, because it's the exact same thing. However I doubt that's what the case the original article is talking about.


So there is a specific role and skillset for DevOps engineers (going by the original usage of the term), correct? Don't you feel that if you can hire a “DevOps engineer” for a specific role on a software team then we have all lost at using the phrase DevOps?


> So there is a specific role and skillset for DevOps engineers (going by the original usage of the term), correct?

Be careful with that misquoting there: I said "different skillsets", I didn't say necessarily roles. An Ops and a DevOps person will know different things.

> Don't you feel that if you can hire a “DevOps engineer” for a specific role on a software team then we have all lost at using the phrase DevOps?

So, you copy-pasted this from the article. If so I'll assume you're agreeing with them and this conversation can be over.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: