Technical Debt: Is it good or bad?
Introduction
Throughout my experience with different teams, technical debt has always been a key issue. While some teams managed it effectively, others were significantly impacted by it, and there was even one company that failed primarily due to unresolved technical debt.
I want to explore what is this referring to as a popular topic, and the reasons behind some people talk about this with fear and curiosity. Is there any trade between perfection and speed??
Let’s take a look at this.
What exactly is technical debt?
There are plenty of definitions, and most of them explain that technical debt is something undone that must be solved or “paid” if we talk in monetary terms.
As with every debt. There is some “interest” that increases as time passes and sometimes becomes unsustainable. Searching online for the origin, I found out that the programmer Ward Cunningham introduced the term in 1992 as part of a comparison between engineering and finance. “Shipping first-time code is like going into debt,” he explained. Unless you pay it down (by keeping your code up-to-date) it will gradually accumulate interest (bugs) until you can’t build anything new. Some misunderstandings show people commonly mistake technical debt for "code we're afraid to touch" or "dumb decisions made by our predecessors." It is understandable the intention of that adjective, but is not exactly what it means and It should be avoided.
How is the technical debt created?
Creating software is commonly compared to creating a house, as you understand an architect makes the plans and design, some developers build and work in the construction, and maybe some UX/UI professionals work with the art and deco. But the reality is:?
Making software is more like taking care of a garden than building a house. It's alive and always changing, not set in stone. When you start a software project, you plant different ideas and features, just like seeds in a garden. Some of these ideas grow well, while others might not work out and need to be removed.
As your software grows, you might move things around to make them work better together, just like you'd move plants to get the right amount of sun or shade. Sometimes, parts of your software get too big or messy, so you need to trim them down or clean them up, like pruning overgrown plants.
You also need to keep an eye out for bugs or problems in your software, which is like pulling weeds in a garden. And when some parts of your software need extra help, you give them more attention or resources, like giving plant food to your garden.
You're always watching how your software is doing and making changes to keep it healthy and working well. This might mean adjusting how it's built, adding new features, or improving how it runs - just like you'd care for the soil, adding new plants, or changing the layout of a garden.
Remember, software, like a garden, is always growing and changing, and needs constant care to stay healthy and useful.
So, returning to technical debt, if the software is not under constant renewal on coding, taking care of bugs, and updating the product. This will eventually create a technical debt.?
领英推荐
Tech debt is expensive
People often say tech debt is bad because it costs a lot. I wanted to figure out just how much it costs. But it's not like a bank loan where you can see the interest rate clearly written down. With tech debt, it's much harder to know exactly what the cost is.
It depends on various factors such as the speed to solve a problem, the team involved in re-restructuring, the tech resources involved in sharpening the product, and many others.
But yes, most of the time. Tech debt is not cheap.
Who is the villain here?
When people talk about Tech Debt, they often say something like: "The old team messed up, but we're smarter now."??
“Our team is going to fix what they did”, “They were not professionals like us”, “This situation could be anticipated if the previous team had ownership”, and so many other team comments…
The truth is that everybody wants to do a nice job. But no one is smart enough to assume problems during a sprint. It could be tons of reasons to move forward while completing what the project manager requires, some developers had to fight with time, money, or other resources. But we can not condemn them to be the villains or the people behind the tech debt.?
Good technical debt
If you got here reading this article and just mentioning bad things and creating some fear-respect to technical debt, is now time to talk about what reason can exist to think the technical debt is something good.
Let me tell you a story:
Ethan, a friend of mine, joined an early startup in 2017, with a team of 7 developers. Two years later, a freshly hired developer complained that the first mobile app was built using React Native, instead of a native technology like Swift for iOS. Ethan had to remind this person that before being a scale-up with 50+ engineers and 6 dedicated team of mobile developers, the initial mobile app was built by the only front-end engineer. He didn’t know any native language, so he used what he knew and released an MVP in less than a month. Thanks to this quick MVP, the company acquired thousands of clients. This sales traction allowed us to raise a series B, and with this money, we hired a dedicated mobile developer to build a native app. His salary was literally paid by financial debt that was raised thanks to the technical debt.
So there are plenty of scenarios where the technical debt can be good too, bringing up new challenges on teams on apps and of course to all the C-level directory refreshing the developing environment.
Conclusion
Let's think about tech debt in a good way. It's like a tool - not good or bad on its own, but it matters how you use it. Think of it like borrowing money. If you borrow too much and never pay it back, you'll be in trouble. But sometimes, borrowing money can help you start a business or buy something important. It can give you time to grow and get customers. It can help you finish projects you're stuck on. So tech debt can actually be helpful if used right. Just remember to respect the work that was done before you came along. The old solutions might look outdated now, but they probably made sense at the time.