If technical debt behaves like a financial debt, logical debt behaves like a learning debt, which is much more impactful.
Once upon a time, there were software developers who ignored best practices like Domain-Driven Design; they took shortcuts to deliver their products quickly. They thought, “We get paid to write code, not design!”
The product manager, in turn, ignored what the development team ignored. She was not even able to name what they all were neglecting. But they were convinced that anything other than writing code was a waste of time. She thought, “Clients pay us to get working software!”
On the launch day, some 30 minutes after the launch, the ‘working software’ collapsed due to the unexpected — so unmanaged — massive amount of concurrent users. In the client’s words, the product manager and the development team must solve a critical issue ‘immediately.’ Launch aborted.
After a sleepless night, when the shortcuts decided during the build phase of the ‘working software’ showed gross mistakes, the critical issue seemed solved. The product manager and the development team eagerly await users to try their product again.
The day after, the fixed product was available for users. Some 30 minutes after the release, the phone rang in the product manager’s office.
“All users’ feedback is that your product is inoperable! Even the simplest operation takes many unintuitive steps!” — The client’s CEO screamed.
“We delivered the best the underlying technologies allow. Let me explain. The API framework 13.19.9 had a patch with breaking changes…” — The product manager answered authoritatively.
“Are you kidding me?” — The client’s CEO shouted.
“It’s software, and you should understand that…” — tried to continue the product manager.
“You must understand that I pay for a service! I don’t care what happens behind the scenes! I want you to hide any complexity! Users need to be productive thanks to your services, not despite them!!!! — The client’s CEO shouted further and interrupted the phone call.
After many sleepless weeks, the product manager — who started to understand the profound mismatch between the business and technological mindset — realized that the product design was wrong and, even worse, not cohesive. She shared her findings with software engineers.
“We integrate the best available technologies to match the time-to-market you demanded. If you wanted so many bespoke behaviors, we needed to write 80% of services from scratch, and it’ll take more or less one year more.” — Software engineers answered.
“I trust you, but you didn’t answer my question, ‘Did you design the product based on user scenarios?’” — The product manager replied.
“You didn’t provide any user scenario. We designed the product to support whatever scenario. Users can do everything they want.” — The software engineer’s leader proudly said.
“Let me understand better and show me the logical design that’d make our product capable of doing whatever users want.” — Asked the product manager.
“We integrated out-of-the-box services. Each service is responsible for a set of behaviors. You can read how services behave in their documentation.” — Quietly answered the software engineer’s leader.
“Do you mean you developed the product with no global design in mind?” — Asked more and more worried, the product manager.
“Of course, we have a drawing of the product architecture! We have a full whiteboard; look!” — Responded outraged the software engineer’s leader.
“That’s incomprehensible!” — Complained the product manager.
“That’s software, and it’s your problem not to understand the architecture!” — Shouted the software engineer’s leader.
“No, it’s our problem! Our client left us and will buy a competitor’s product.” — Communicated the product manager.
Nobody spoke.
“Our lost client said something utterly simple we ignored: ‘I pay vendors to solve problems! Instead, you sold me unstable solutions fully misaligned with the users’ problems! This is a deal-breaker! Bye!’” — Concluded the product manager.
“We’ve always worked like that. And we had success.” — Said the software engineers.
“Me too. But this time, we failed.” — Whispered the product manager.
The story above shows the logical debt in action. People act like they “have always worked” and are focused on solutions, almost ignoring the definition of the problem, which is the only reason clients and users pay for software and services.
Vlad Khononov says in Learning Domain-Driven Design:
Equipped with the knowledge of the system’s business problem, you will be much more effective at choosing the appropriate solution.
That’s utterly simple! It’s so simple that it’s so easy to ignore as something obvious software engineers can skip.
The team of the above story — product manager and software engineers — started developing their product by rooting its design on integrating a bunch of technologies that were supposed to cover whatever use case. They focus on a sort of silver bullet solution that cannot exist.
Instead of inferring the solution based on a defined set of problems of their users, they tried to provide the broadest possible range of solutions around the business of their product. They delegated the definition of the problem to the technologies they integrated. That’s the fatal shortcut.
Why? Vernon Vaughn, in Domain-Driven Design Distilled, answers:
Developers don’t give proper emphasis to naming objects and operations according to the business purpose that they fill. This leads to a large chasm between the mental model that the business owns and the software that developers deliver.
That’s the origin of the logical debt: a mindset mismatch between who builds products — the product manager and software engineers of the story above — and who buys the product, who pays to get problems solved.
It’s so simple: if you sell something, put yourself in the shoes of the potential buyers and think as they think by using the exact words and concepts.
If what I described here resonates with your experience, please leave a comment with your thoughts!
Logical Debt Is Much More Devastating Than Technical Debt was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.