If technical debt is behaving like financial debt, logical debt is behaving like learning debt, and its impact is much greater.
Once upon a time, there were software developers who ignored best practices like domain-driven design. They took advantage of shortcuts to deliver their products quickly. They thought, “We get paid to write code, not design!”
Meanwhile, the product manager ignored what the development team ignored. She couldn’t even name what they were all ignoring. But they were convinced that anything other than writing code was a waste of time. She thought, “Our clients are paying us to get software that works!”
On launch day, about 30 minutes after launch, an unexpectedly large number of concurrent users caused the unmanaged “working software” to collapse. In the words of our clients, product managers and development teams need to solve critical problems “on the fly.” Startup has been aborted.
After a sleepless night, the critical problem seemed to be resolved when a critical mistake was made in the shortcuts decided during the “working software” construction phase. Product managers and development teams can’t wait for users to try the product again.
The next day, the corrected product was delivered to users. About 30 minutes after the product release, the phone rang in his manager’s office.
“All the user feedback is that the product doesn’t work. Even the simplest operations require many unintuitive steps.” — exclaimed a client’s CEO.
“We delivered the best that the underlying technology allowed. Let me explain. There was a patch in API framework 13.19.9 that contained a breaking change…” — a product manager gave an authoritative answer. Did.
“Are you kidding me?”—screamed the client’s CEO.
“This is software and you need to understand it…” — the product manager tried to continue.
“you I have to understand that I am paying for a service! I don’t care what happens behind the scenes! I want you to hide complicated things!Users need to be more productive thank you not your service, in spite of they! ! ! ! — The client’s CEO yelled more and interrupted the call.
After weeks of sleepless weeks, a product manager begins to realize that there is a serious mismatch between business and technology thinking. I noticed. She shared her findings with her software engineers.
“We integrate the best available technology to meet time-to-market. you he demanded. If he requires so many bespoke movements, he will have to create 80% of his services from scratch, and it will take him over a year. ” — replied a software engineer.
“I trust you, but you didn’t answer my question: ‘Have you designed your product based on user scenarios?'” – the product manager replied, “
“you No user scenarios were provided.We designed our products to support anything scenario. Users can do whatever they want. ” – said the software engineer leader proudly.
“Can you help me understand more and provide a logical design that allows our product to do everything our users want?” — asked a product manager.
“We have integrated ready-to-use services. Each service is responsible for a set of actions. You can read how the services work in the documentation.” — Software Engineer Lead Quietly answered.
“Are you saying you developed it without thinking about global design?” — asked the product manager, growing increasingly worried.
“Of course we have product architecture drawings. We have a full whiteboard. Look!” — to which the software engineering leader was furious.
“I don’t understand that!” — complained to the product manager.
“It’s software, and it’s your The problem is not understanding the architecture! ” — exclaimed a leader of software engineers.
“No, that’s our problem! Our customers plan to leave us and buy our competitors’ products. ” — I contacted the product manager.
No one spoke.
“A lost client said something completely simple, but we ignored it: “We’re paying a vendor to solve a problem!” sold unstable solution Completely inconsistent with user opinion problem! This is a breach of contract! Goodbye!”—Product his manager concluded.
“That’s how we’ve always worked. And we’ve been successful.” — said a software engineer.
“Me too. But this time I failed.” — the product manager whispered.
