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 mean examine? Professional language helps us to be precise, but certain words obscure more than they clarify. I’m so used to jargon terms that with no effort I’ll let familiar words fool myself.

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 losses. Everything else is an attempt 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” is 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 that has 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 expectations about low quality to senior managers or to hit the deadline 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’m eager to learn what criteria were considered to 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’s going to happen after the “MVP” launch? If the next step is to spend three months fixing the technical debt the team created during the “MVP”, it certainly violates the spirit of the idea.

In some cases, “MVP” is an instrumental approach to deal with uncertainty and to discover customer needs. But sometimes it’s a disguise for sloppy decision-making or a political tool to gain executive presence.

Technical debt

This is one of my favorites. Engineers tend to call any technical improvement a “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. It takes effort to run systems in production. Software maintenance resembles gardening—maintaining a beautiful garden requires ongoing effort. The longer you neglect it, the more weeds grow. It’s not debt—you don’t pay interest on it. It’s simply work that needs doing. You can do it yourself, you can delegate it, or hire someone to do it. You can’t ignore it. Otherwise, you won’t have a garden.

Another cluster often labeled as “technical debt” is the evolution of architecture and tech stack modernization. It’s the frustration about legacy systems or the programming language that urges engineers to rewrite everything in GO/Rust/put-your-technology-here. I understand that urge to rewrite legacy systems, but without a solid engineer strategy, such rewrites create more harm than good. “Just rewrite in ” is almost never a good idea. Who will maintain that? How easy it is to hire people who can maintain that? How others teams will be able to contribute? An engineering strategy must cover these and many more questions before jumping into a new technology.

The third category within “technical debt” is the uncertainty of the domain. As the team learns more about the problem space, they will discover that some initial assumptions aren’t true. We thought one 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 the understanding of the domain grows, the codebase needs to reflect these learnings. This is what Ward Cunningham, who coined the term, meant by “technical debt.”

The original meaning has never been about writing sloppy code to push things into production faster. Mr. Cunningham is vocal about this misconception: https://youtu.be/pqeJFYwnkjE?si=yCD9_SGo2fi9mg8p

What makes “technical debt” a buzzword is the misinterpretation among engineers that it’s OK to cut corners by not writing tests, ignoring code complexity, and neglecting readability of the code. As long as this distorted thinking exists, what makes you believe that next time the engineers will do a better job?

To be added

• Scope
• Agile
• Strategy
• Vision