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

Phrases in computing that might need retiring

sicpers.info

Post reply on HN
Print view View original

141–150 of 291 posts

Re: Phrases in computing that might need retiring

#141

Post by spoiler »

peacemaker wrote: post #64
fishbacon wrote: post #25

Earlier quoted context omitted.

DevOps has in my experience become full stack + server maintenance + misc tool development.

I recently moved from software dev to devops and this sounds about right! I'm supposed to understand the product teams entire codebase, write the tooling, create/update terraform for the infra, implement CI/CD stuff plus act as some kind of IT guy with AWS access. Don't get me wrong, it makes a nice change from pure development, but it's clear that in most places, 'DevOps' is not so clearly defined.

Yeah, likewise. Alongside that I'm also expected to do backend development. I feel like I'm allowed no downtime or get any "easy wins". I wonder if that can quicken burn out onset

Re: Phrases in computing that might need retiring

#142

Post by munch117 »

chriswarbo wrote: post #81
wheybags wrote: post #51

"Continuous integration" just means "automated tests on every push", and no longer means anything much to do with integration, which I always found kinda funny. It sometimes even means automatic running of scripts that aren't even tests, like automatically generating html from markdown on push. You could say that's continuous deployment, not CI, but you'd be fighting a losing battle. The yml file you wrote to run the…

> no longer means anything much to do with integration, which I always found kinda funny. I thought the point of CI was to avoid (what we would now call) long-lived feature branches; e.g. a team spending 6 months on their own copy of a codebase, then struggling to merge it back into the mainline when finished. In other words, CI isn't just about running tests on push; it's about the frequency of pushes, often several…

When the term 'continuous integration' was originally conceived, the point was to avoid branching altogether. It was not features branches that was the problem (there was no such thing at the time), the problem was synchronising work between groups that were working on different parts of the same application.

So the original CI server concept was that everyone would get a nightly update. Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived.

I'm not convinced that it's a good thing that you and so many others have stopped questioning feature branching.

Re: Phrases in computing that might need retiring

#143

Post by bob1029 »

robsws wrote: post #129

Hard agree on AI, hard disagree on Tech Debt. The sheer force of opinion saturated into so few words made me smile :) My highlights: - OOP 'modules, but using the word class' - Agile 'It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks' - AI 'an algorithm pushed to production by a programmer who doesn’t understand it'

> AI 'an algorithm pushed to production by a programmer who doesn’t understand it'

This is precisely how I read it too. The microsecond I hear a person say “AI” or “ML”, I’m thinking “oh ok so it’s untraceable, non-deterministic bullshit I’m gonna be held responsible for if I approve this.”

Probably still net profitable to continue using this marketing language. Certainly does me a favor too.

Re: Phrases in computing that might need retiring

#144

Post by madsbuch »

eru wrote: post #125
madsbuch wrote: post #41

Earlier quoted context omitted.

The problem with tech dept is that it instills some kind of linearity -- you can pay it off whenever. Often times "tech dept" comes from the fact that we do not truly know what to build. Hence we use the simplest measure to satisfy what requirements there are. Call it the "Occam's razor of software development".

Truth be told, because nobody knows anything, it's often easier to deal with an "Occam's razor" designed system that tried to stay simple; than with a prematurely overengineered mess.

Ah yes, sorry, I was unclear in my original comment.

Te point is to stick to the simplest implementation and don't try to reduce "tech dept" in favor of building premature optimizations.

I am very much for dropping the tech dept term

(https://www.madsbuch.com/assumptions/)

Re: Phrases in computing that might need retiring

#145

Post by quickthrower2 »

Avamander wrote: post #138
quickthrower2 wrote: post #131

Earlier quoted context omitted.

There are some differences between “tech debt” and “debt”: Debt has to be serviced, and if it isn’t some asset is probably forfeited or you can be forced into bankruptcy. Not so for tech debt. Debt is known for certain in a measurable quantity. Tech debt is not measurable and only exists to the extent people argue it exists. Two engineers may disagree in how much tech debt there is. Debt can be used to fund things wi…

> Debt has to be serviced, and if it isn’t some asset is probably forfeited or you can be forced into bankruptcy. Not so for tech debt. It is so for tech debt though. If you keep on accumulating it, at some point it's gonna have very negative effects: a ransomware incident, data leak or even a total company-wide standstill.

Say you have a product, and you add no new features (you fix some bugs and patch for security). The interest payments are a lot less than if you are actively developing new features and therefore adding complexity.

So it is dynamic in a way that normal debt isn’t.

It can be worse than debt or not as bad depending on the nature of the debt and its consequences.

If you have something written in OG Perl and and the messyness makes all your devs leave and you cant find anyone with skills that can be really bad! Although only if that product is your ownly source of revenue.

Say like many small companies trying to make it big you have “bread and butter” product A and “next gen unicorn” product B.

If B is far along and customers transitioning from A to B then tech debt on A is less expensive than if B is stalled and in a quagmire.

Re: Phrases in computing that might need retiring

#146

Post by tpxl »

srvmshr wrote: post #94
tobych wrote: post #3

Perhaps "API" could be added to this list. I've been jobhunting this week, and first I heard recruiters use "API" to refer to what I'd call a "service", then heard other quite senior developers do the same thing.

APIs, frameworks & libraries are so often being used interchangeably & its getting confusing for us too, specially if planning for a new feature to integrate "is it a framework? is it a library? is it a API" whenever I have a cursory glance at a product on HN/Github or likewise

I mean, a library has an API (the public facing stuff you're supposed to use), a framework probably also has an API (or rather, a bunch of them), and a service also probably has a Web API (assuming you're programming against said service).

Re: Phrases in computing that might need retiring

#147

Post by ratww »

olalonde wrote: post #140

> 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…

> 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.

Re: Phrases in computing that might need retiring

#149

Post by samatman »

ghayes wrote: post #15
edrxty wrote: post #8

Strong disagree on "technical debt" Rather, the entire world is built on it and there's some level of acceptance required, but we definitely need a shorthand phrase for "we're doing something stupid that will save us time now and make us hate ourselves a year from now" Edit: thinking on it, also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of ever…

Right, and "debt" is a beautiful word here. It accurately describes receiving the value today, but then owing that time back, with interest, in the future.

I agree completely, it's a powerful concept, just too narrowly applied.

The 'technical' part points out that it's a special kind of debt, one that isn't measured directly in money. What's the debt? The debt is time.

You can't move some technical (which isn't a noun), or some money (which is), from one account to another, to pay down a time debt. You have to pay it off with skilled labor, which takes time in a way that isn't fungible with money: there's a lot of COBOL out there which can be lightly modified, or replaced, but that company can't find the hours of skilled labor to do more with it, at any price.

A codebase isn't the only time debt a company can incur, any process can be stuck in a suboptimal frame because no one wants to sign off on the time it would take to make it right.

Re: Phrases in computing that might need retiring

#150

Post by hackernewds »

jmfayard wrote: post #59
InCityDreams wrote: post #46

Earlier quoted context omitted.

Genuine question. Why bother downvoting, and not just move along? Perhaps there should be a button for 'disagree strongly'.

Those are polar opposites. A button for 'disagree strongly' should upvote a comment. When Einstein and Niels Bohr 'strongly disagree' on quantum physics in 1927, they start a debate that makes both of them more enlightened. When a bullshit artist, who couldn't care less about the truth, hijack a discussion to make it all about Him (it's almost always a dude), everyone become dumber. "Moving along" is not enough becau…

> make it all about Him (it's almost always a dude)

eyeroll

Post reply on HN