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

81–90 of 291 posts

Re: Phrases in computing that might need retiring

#81

Post by chriswarbo »

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 times a day.

Perhaps it's a good thing that such practices have become so ubiquitous (largely thanks to DVCS) that we don't really think of the alternatives any more :)

Re: Phrases in computing that might need retiring

#82

Post by y4mi »

TheOtherHobbes wrote: post #42
ghayes wrote: post #15

Earlier quoted context omitted.

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.

Except it doesn't. It's a one-sided and misleading concept. The problem is usually finding a balance between "Let's hack some suicidally awful crap together quickly to see if we even have a market and then fix it when we have real income, except everyone knows we won't so it will be a permanent drag on the business" and "Let's build a beautiful extendable maintainable paragon of elegance and purity and ignore the fac…

It's usually only a "beautiful extendable maintainable paragon of elegance and purity" in the eyes of the original architect. Everyone else sees it as leaking abstraction with bolts everywhere to keep the original idea somewhat working... Or just a massive pile of technical debt.

Code quantity is always dependent on how well the person making this judgment understands the software. While I'm sure that everyone will agree that there are some clearly better ways of doing things, they sure as hell won't all agree on what these clearly better ways are.

One person's pile of garbage is the next person's perfect implementation with easy to understand procedural logic.

Please take note that I'm explicitly not saying that any implementation is better then another. I'm just trying to convey that the term technical debt very much depends on the mindset of the person looking at the implementation

Re: Phrases in computing that might need retiring

#83

Post by ebingdom »

> Reasoning About Software

What's wrong with this? I need a way to describe techniques that make it easier to...well I don't even know another way to say it. Maybe I'm biased by my experience in formal verification, a field in which it's expected that you can formally study a program's behavior.

Re: Phrases in computing that might need retiring

#84

Post by crdrost »

drewrv wrote: post #35
ghayes wrote: post #15

Earlier quoted context omitted.

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.

Tech debt is one of the few metaphors I love because it’s so accurate. What a lot of engineers struggle with is that manageable levels of debt is fine for a business and in fact superior to being cash constrained. Some forms of debt are a headache if the business goes south but tech debt can be ignored if the software project goes nowhere. So the “terms” are good. Rather than complaining about tech debt, one should c…

I agree, and I love the metaphor too, but you have to admit that something about the metaphor isn’t reaching peoples’ brains the way a good metaphor does.

A good litmus test here is to ask someone, “what if I told you that technical debt was originally a good thing?”... Like “Yes! Let’s go and get some technical debt, it will be great!” And so, can you understand why it might have started out that way?

People who really get the metaphor, can understand why it was originally a good thing to be desired. Because debt is a useful tool for the same reason, and if you can pursue what “being unable to take on technical debt” looks like, you can understand that it was a reaction to waterfall-style approaches.

But a solid 80-90% of people in tech don't understand how it could possibly be positive... “tech debt” is just a shorthand for the stuff that is causing development to go slower than you would have liked it to go.

Re: Phrases in computing that might need retiring

#85

Post by helpfulmandrill »

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…

I think "technical debt" is a good metaphor, as long as you recall that taking on debt to fund investment can be a good idea sometimes. Debt isn't always bad in the long term.

Re: Phrases in computing that might need retiring

#86

Post by mikewarot »

Technical Debt is a very descriptive term that everyone can relate to. The problem is we don't have a consensus on the nature of the interest on the debt, and what happens when it doesn't get paid back.

In my opinion, most technical debt has usurious interest rates.

Re: Phrases in computing that might need retiring

#87

Post by chriswarbo »

labrador wrote: post #48

"Blah blah considered harmful", "code smell", "anti-pattern" I hate them because they've become slang for any code that isn't written the way we like

Also describing any software as "modern".

I find this especially amusing when it's used to describe things that are 50 years old (e.g. programming languages with "modern" features like type inference)

Re: Phrases in computing that might need retiring

#88

Post by TT-392 »

peterkelly wrote: post #30

"Full stack" (except when referring to someone who can do everything from CPU design and assembly programming right up to UI work)

I am an EE, that works with microcontrollers on a daily basis. I know some html I play around with sdl and ncurses a bit, I can do some internet stuff. I am clearly a full stack dev right?

Re: Phrases in computing that might need retiring

#89

Post by TT-392 »

TT-392 wrote: post #88
peterkelly wrote: post #30

"Full stack" (except when referring to someone who can do everything from CPU design and assembly programming right up to UI work)

I am an EE, that works with microcontrollers on a daily basis. I know some html I play around with sdl and ncurses a bit, I can do some internet stuff. I am clearly a full stack dev right?

Oh, and I designed an UI for my smartwatch OS. For which I wrote everything from the ground up.

Re: Phrases in computing that might need retiring

#90

Post by jon-wood »

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…

> also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of everyone's shit" but with a flashy name that sounds important so mgmt will agree to it

If that's what "devops" is now, sure, kill the term. Devop is not a job title, and I will die on that hill. The concept of DevOps is close collaboration between development and infrastructure teams throughout the development process, rather than throwing things over the wall and saying "that's infrastructure's problem now". Having a completely separate team entirely misses the point because it should be one team.

Post reply on HN