I’m sitting in a meeting, nodding along as a coworker says something. A moment later I realize that I didn’t catch the meaning of the last sentence. The sentence consists of familiar words, its structure is sound, I heard it clearly. But the message behind the words is murky. What do these words actually mean? Professional language helps us be precise, but certain words obscure more than they clarify. I’m so used to jargon that I let familiar words fool me without effort.

Over time, I built a list of words that helps me to stay alerted. When I hear one, I know that I’m in a foggy area. It’s the moment to listen carefully and to seek clarity.

Here is my list of buzzwords, with comments and thoughts that help me see through the fog.

Deadline

It’s used constantly, most of the time for no good reason. The only real deadlines are those that cause financial or reputational damage. Everything else attempts to use a forecast as a commitment. Delivering necessary changes to launch Black Friday sales, launching functionality before a multi-million marketing campaign goes live, and ensuring compliance with new legislation before its effective date are deadlines. An executive frowning when something gets postponed is not.

Surprisingly, organizations obsessed with “deadlines” rarely deliver projects before the due date. In such cultures, “deadline” becomes a political tool to avoid accountability and push problems into the future. Whenever I hear the word, I ask “what is the financial or reputational risk of missing this deadline?” Is there any?

MVP

Stands for Minimum Viable Product. A product with just enough features to satisfy early customers and provide feedback for future development. The original intent is good—build just enough to discover what works.

But managers label something as “MVP” to set low-quality expectations with senior managers or to hit deadlines at the cost of usability and maintainability. Whenever I hear “MVP”, I focus on one letter at a time.

First, I think “is it a product?” Does this thing have profit and loss that make it economically viable? Most of the time it’s not. I once was presented with “MVP of the next generation architecture”—whatever that means.

Second, I examine the viability. I want to learn what criteria define viability, which ones were selected, and which were filtered out.

Finally, I examine the “minimum” aspect—What is the plan to grow from the minimum into a solid product? What will happen after the “MVP” launch? If the next step requires spending three months fixing the technical debt the team created during the “MVP”, this certainly violates the spirit of the idea.

In some cases, “MVP” provides an instrumental approach to deal with uncertainty and discover customer needs. But sometimes it disguises sloppy decision-making or serves as a political tool to gain executive presence.

Technical debt

This is one of my favorites. Engineers tend to call any technical improvement “technical debt”. Product managers often get frustrated about “technical debt” because they don’t fully understand what they’re actually paying for.

When I dive into specifics about the meaning of the term, I see three distinct categories.

Much of what we call “technical debt” is just work. Running systems in production takes effort. This includes updating dependencies, applying security patches, upgrading infrastructure, and more. The day you put a software system live, maintenance kicks in. It’s not debt—it’s work that needs doing to keep the system running.

Software maintenance resembles gardening. Maintaining a beautiful garden requires ongoing effort. The longer you neglect it, the more weeds grow. You can do it yourself or hire someone to do it. You can’t ignore it. Otherwise, you won’t have a garden. Calling such maintenance work “technical debt” does a bad service. It implies the work is optional and can be ignored. If we want an economic analogy, let’s call it “technical tax”—paying taxes is not optional.

Another cluster often labeled as “technical debt” is the evolution of architecture and tech stack modernization. Technologies become obsolete. What was a unique feature becomes a commodity. A home-built tool that was groundbreaking back then gets beaten by open source alternatives. This isn’t debt—it’s progress. If we need an economic analogy, this is depreciation: assets lose value over time.

Labeling this evolution as “technical debt” serves no purpose. Following the urge to “rewrite everything in Go/Rust/” will do more harm than good. Yes, working with legacy systems and outdated programming languages might be frustrating, but moving to a modern tech stack is not the solution. You need a plan. An engineering strategy to keep up with progress.

Who will maintain the new stack? How easy is it to hire people skilled in this technology? How much effort does it take to migrate to a new stack? An engineering strategy must cover these and many more questions before jumping into a “cool new tech stack.”

The last bucket of “technical debt” is the gap between the domain and how the software system models it. As the team learns more about the problem space, they discover that some initial assumptions aren’t true. We thought a user would have only one account, but it turned out that one user can have multiple accounts and our system doesn’t support that. As understanding of the domain grows, the codebase needs to reflect these learnings.

That’s what Ward Cunningham meant when he coined the term “technical debt.” When you don’t understand the domain, model it just enough to support current needs, and refactor it when your understanding improves.

The original meaning was never about writing sloppy code to push things into production faster. Cunningham’s point was about acknowledging uncertainty and making progress. He is vocal about this misconception: https://youtu.be/pqeJFYwnkjE?si=yCD9_SGo2fi9mg8p

This misconception makes “technical debt” a buzzword—the belief that it’s OK to cut corners by not writing tests, ignoring code complexity, and neglecting readability. As long as this belief persists, what are the chances that the next big rewrite won’t be a waste of time?

To be added

• Scope
• Agile
• Strategy
• Vision