Live data from Hacker News

Phrases in computing that might need retiring

sicpers.info

111–120 of 291 posts

Re: Phrases in computing that might need retiring

#111

> "Agile: Nope, this one’s in the bin, I’m afraid. It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”. We have to find a new way to discuss the idea that maybe we focus on the working software and not on the organisational bureaucracy…" Yup. :-(

Well, it's very difficult (and probably mis-guided) to throw away waterfall completely. In reality, most "not waterfall" approaches are just "smaller waterfalls" with less formailty. You still need some semblance of requirements (what you want to build), some amount of design, you need to implement, you need to test, and you need to maintain. Those steps could take months, weeks, days, hours, or minutes. And they cou…

In my world, the detailed design happens as late as possible, and is quite fluid, as we get feedback from the implementation. This is certainly my main take away from DDD.

In waterfall as I understand it, each step is separated in time and team, and the feedback loop from implementation is lost.

Re: Phrases in computing that might need retiring

#112
post #35
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 think those who object to the metaphor do so because they interpret "technical debt" as "technical consumer debt". Consumer debt being a relatively benign form of debt, they don't believe it conveys the gravity of the matter at hand.

Consumer debt is mostly unsecured, almost perfectly fungible across term structures and refinanceable on a whim within a very competitive market of lenders. It's rare for it to be essential for a consumer to take on debt to continue to live[1] and there are typically safeguards in place to ensure consumers don't take on too much debt burden. The only debt that most consumers will come across that imposes any restrictions, or moves slowly, is a mortgage on a residential property. When we talk of "technical debt" we are talking of something has none of the nice properties of consumer debt. If I had sufficient cash I could pay off all my consumer debt within two minutes with a few taps of my phone screen.

On the other hand, I interpret "technical debt" to be akin to a complex structured financial product. Maybe there are convertability clauses between debt and equity, perhaps there is variability in the rates payable, or optionality that can be triggered by various real world events. This form of debt is not liquid, it is not refinanceable and it can be hard to find someone to take it off your hands for any amount of money! Nonetheless, sometimes it is essential for a business to take on this sort of debt to continue to thrive. That is an apt meaning for "technical debt" in my opinion.

[1] rarity depends on how socialised one's healthcare system is!

Re: Phrases in computing that might need retiring

#113
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 throughou…

This is the problem I suppose, that the definition is fuzzy. I'd say it's to have teams where "you build it; you run it" and so the dev and ops are done by one team. That means teams will produce things that are easy to operate, as they'll be doing it.

Re: Phrases in computing that might need retiring

#114
I do find “BDD” a frustrating term.

It was coined by Dan North [0] to refer to a coherent set of sensible TDD practices — give tests expressive names, say “behaviour” not “test”, write executable “given/when/then” acceptance criteria — but in the intervening 16 years (!) it’s mutated into… I don’t even know what.

There’s a community of “BDD” practitioners who talk about all sorts of ideas that aren’t necessarily even specific to software engineering. Which is fine and good, but it’s rendered the term essentially meaningless in a software context.

These days I usually say “double-loop TDD” or “outside-in TDD” when I want to emphasise the use of executable acceptance tests; it’s impossible to predict what (if anything) “BDD” will mean to anyone.

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

Re: Phrases in computing that might need retiring

#115
post #63
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…

In Corporate and Enterprise environments, the term 'Technical Debt' is now commonly used for systems and platforms that are beyond their supportable lifecycle, but are still in use for reasons , yet need to be replaced as soon as possible. These systems were never just hacked together with the knowledge they'd be problem in the future.

It's known now that they're a problem, and they're choosing right now to continue with that problem rather than spend the time/money/effort to change them. That's still technical debt. If it helps, you can see it as starting right now, rather than when the code was written. Either way, they're choosing to continue to have problems rather than pay off that debt... yet.

Re: Phrases in computing that might need retiring

#116
post #63

Earlier quoted context omitted.

In Corporate and Enterprise environments, the term 'Technical Debt' is now commonly used for systems and platforms that are beyond their supportable lifecycle, but are still in use for reasons , yet need to be replaced as soon as possible. These systems were never just hacked together with the knowledge they'd be problem in the future.

Shouldn't those systems be named "legacy system" then?

You'd think so, yes. But... it's Corporate, nothing in those places makes much sense.

Re: Phrases in computing that might need retiring

#117

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…

> Him (it's almost always a dude)

I'm curious as to how you know the sex of anonymous posters.

Re: Phrases in computing that might need retiring

#118

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.

I for one am rather fond of just calling it "one man IT department" or a "generalist" (for whatever reason it looks like this has become a dirty word lately)

Re: Phrases in computing that might need retiring

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

Not sure about that. A large part of the company (everybody close to money) probably see debt as a good thing because it lets them buy stuff. Of course you have to pay debt to creditors and how do they do it? By making more debt. It works well until you have to pay it off, all of it. So if they ever enter in a discussion about technical debt expect them to suggest to make more debt (and move faster.) Building without…

Why would you have to pay off all the (financial) debt?

Debt can be a permanent part of your company's capital structure just like equity can be a permanent part. Or do you have a plan to buy back all outstanding stock?

(Yes, real world debt in the form of bonds a due date, when you have to roll it over. But that's an accident of history. Instead companies could also sell perpetual bonds and put options on those bonds for the same effect.)

In finance terms, loosely speaking debt is the part of your capital structure whose cost is fixed in nominal terms. Equity gets the remainder of your income stream.

About high leverage: the more of your income stream you parcel out for fixed payments, the more you 'concentrate' your equity and the variability of the residual income it gets.

(Overall, I blame tax systems that give preferential treatment to debt over equity. Roughly, you can pay the capital cost of your debt with pre-tax money, but the capital cost of your equity comes out of post-tax money. Put them on equal footing, and you'll solve quite a few problems.)

Re: Phrases in computing that might need retiring

#120
post #84
post #35

Earlier quoted context omitted.

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

The big difference between technical debt and actual debt in a money sense is that real debt is taken on consciously with an agreement betweenn debtor and lender. Because of this money debt can be worked into the planning and the risk can be calculated at the time the loan is initiated. Circumstances can change over time, but there is a bargain between the debtor and the lender. There are things like interest rates and collateral that are agreed upon when the debt is incurred.

Technical debt is by definition created to save time, so there is rarely an understanding of the risk that comes with the debt until the debt must be repaid. This means that the eventual payback can range from inconsequential to disasterous. The point is that the debtor won't know until it comes time to pay the debt back. Technical debt is often incurred in lieu of actual planning, not because a debtor is consciously and rationally weighing current reward against a future risk.

Post reply on HN