Hacker News Reader

All those phrases originally meant something. I think they become management speak via two mechanisms: 1. People use them shorn of their original meaning to deliver the appearance of being managerial without the substances or 2. People raise them to rock-solid rules and demand slavish conformance to them without thought about costs/benefits or appropriateness.

For bonus points, mix the two up, so that not only is someone trying to sound managerial but failing by using the terms completely incorrectly, but then also rigidly enforce their incorrect understandings.

For instance, if you have lots of meetings and those meetings almost never produce "action items", and/or those action items never get done, you really do have a problem. If you don't like calling them action items, fine, find another word, but it'll be the same thing. But if you get a manager that insists that meetings always produce action items, no matter what, you get another sort of failure. It is a perfectly valid use of a meeting to get two groups together and just make sure they are on the same page about something. If that's all you ever meet about, there may be a deeper problem you should dig into, this shouldn't be your dominant form of meeting (unless you're in a position where that's your direct job), but it does sometimes need to happen.

I find it useful to dig down to the "original" meaning of a lot of these terms, think about what they mean and how to use them in my own head to put terminology on things, but not to be rigid about it.

I also observe that there are some managers who use the terms essentially correctly, and some that clearly fit into at least one of the two categories I listed at the beginning. They should be treated differently.

I agree with you but I think there is something to the business side. No Sales/PjM/Manager/CFO is likely to want to spend 3 months of resources on non-revenue generating updates. They would rather pay the fiddler when the system has a failure. Just like us humans, people don't change their diet and exercise until AFTER the heart attack.

I'm not actually arguing against prioritizing shipping. My criticism is with the way that people wield language to enforce their choices and avoid responsibility.

Defending a choice means actually defending it.

"If we don't ship this by X date, there won't even be a company to have the problem you're talking about."

"This choice will have less impact than you think for X reasons."

The problem is the specific reasons are often more in the family of "Shipping this is one of my KPIs and I'll be on some other team when the problems you're talking about are realized."

It's not just business vs. engineering anyway. Slow to ship? It's cause of all the tech debt. No tests? It's okay, just tech debt. No docs? Poor abstractions? Lack of understanding about the problem? Low skill with the technology at hand? It's all fine! Tech debt can be your scapegoat or hall pass for anything.

I don't quite agree with the 'for anything'. For poor/missing technical assets that area direct cause of insufficient upfront investment (of time, money, etc), that's 'tech debt'.

Missing/outdated docs/tests? Tech debt.

"Low skill with technology" - probably not as easy to lump it as 'tech debt', imo.

"Lack of understanding about the problem" - again, doesn't seem like tech debt, but... business debt. Tribal knowledge debt. Operational debt, but not explicitly 'tech' debt.

But... perhaps that's your point? It's easier to just say 'tech debt' for everything, even if it's plainly the result of underinvestment on non-tech things?

Yep, exactly my point. The phrase is saturated with meaning.

>"Technical Debt" is this level of crummy metaphor. I love Cunningham's original definition. Do your best to model the business problem with the understanding you have. Later, pay down that debt by refactoring.

I on the other hand hate Cunningham's original definition because the metaphor maps badly, debt is not something that is poorly understand that becomes clearer the more information you have. Maybe that would be Technical Risk.

Your second example:

>"That choice will severely limit our capabilities in the future, and be incredibly hard to change."

>"I'm willing to take on some tech debt to prioritize shipping."

is a better metaphor because debt is the thing you take on that you need to pay off later with some knowledge of what level of debt you have. That said it's still sort of bad because debt would be nice to have sort of a ball park estimate of how much must be paid to get rid of it. If you don't have that estimate to go on it's beyond technical debt, and maybe more like technical favor owed to the mob.

That might be the outcome of not thinking or it might be the outcome of thinking “going out of business [or just canceling the project] will severely limit our capabilities even more and also be incredibly hard to change” and concluding “taking on tech debt is the better choice.”

Conversations like this aren't an outcome of not thinking. They are an instruction to not think. These phrases are software development thought-terminating cliches. https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A...

Weird phrases and jargon are a burden in healthcare. There are literally thousands of terms you can learn that don't have applications elsewhere. As a healthcare IT specialist, you're spoken to in this language of doctors and medicine, and must take diligent notes and learn what all those 3 letter acronyms are so you can get the right diagnoses or drugs in your analyses.