It sounds like the problem you describe is not with the concept of using serverless/faas cloud compute and adjacent services, but with the design and implementation done by some engineers you work with. That may be due to time constraints, lack of familiarity, engineering skill, or some other reason.

I’ve seen terrible containers, terrible vms, terrible bare metal servers. I’ve written good and bad myself. And yes, I’ve seen (and done) great implementation of serverless. It’s all just tools to be used.

This reads as if someone doesn’t understand cloud compute, iac, and so on, and just got frustrated trying to learn and explore the paradigm.

That’s fine, but blaming “serverless” or aws lambda is like blaming a multicore cpu for having to learn threads and subprocceses.

Pdf is more flexible than printing a doc. The format supports layers, so it would avoid losing information if it saves as a layer visible in the default view. This certainly matters in some cases.

Think of the term “debt” here. For example, when you can borrow at a good rate and use the funds to gain an advantage.

If you don’t know what you owe it’s not a problem with the debt, but with your accounting. Personally, I would not trust an accountant who couldn’t keep track of what the company owed.

Identified tech debt goes into the backlog and other relevant documentation however your team handles it. You don’t need specifics, just the knowledge that you’re making the decision.

Now, if most of your tech debt is unidentified, that’s not a problem of the tech debt, but rather of engineering accounting practice.

Really strange. What industry have you seen this in.

In big tech, enterprise, biotech, every team I’ve been on has uniformly understood that technical debt is just a concept of future work that is intentionally put off to focus speed, exploration or some other reason. It’s used in strategic planning to determine the cadence of output.

Aside from new grads this has never been a concept I’ve had to explain to an engineer or pm. Not like a sometimes thing. Literally never. Just very strange.

I am curious who speaks of technical debt as only a negative. I’ve never worked on an engineering or product team that didn’t understand the meaning of the term.