Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Did you know talking about technical debt can help you win at work? Technical debt conversations are not usually a path to promotion. They are more likely to be frustrating and filled with complaints. Many such conversations end with a realization that not much will change. Despite that, there are 3 unexpected benefits of talking about technical debt.
When you talk about technical debt more often you do three things:
Following a recent interview on the Dev Interrupted Podcast, OutSystems CEO and founder Paulo Rosado joined us to chat about his path to founding the company, advice for successful leaders, and the growing threat of technical debt. The conversation below has been edited for length and clarity.
Tell us about OutSystems' founding story. What inspired you to start the company?
There are many ways in which technical debt costs us money: lost deals, customer churn, employee churn, lawsuits, and more. However, there are a couple of issues that are more important than others: engineering time, morale, and the missed revenue from software delays.
Engineering time
Last week we hosted a webinar where Alex Omeyer interviewed Adam Tornhill about technical debt: what is it, why it's important, and how to manage it effectively. For this article, we've chosen some of the most interesting questions we've got from the audience. If you're curious to learn more — check out the full version of the webinar.
Alex: I'm Alex, the Co‑founder, and CEO of Stepsize. I spend all of my time talking about technical debt with Engineering team members, and I'm genuinely pumped to have Adam, CTO and Founder of CodeScene, with me today.
Have you ever heard the saying, 'architects hate spaghetti?' As software architects, it is our responsibility to envision and design systems capable of supporting the cutthroat business models of this era. In that sense, it's fundamental to develop ways to evolve our application architecture to match business concepts and processes correctly. Otherwise, the architecture won’t be structurally sound, and we’ll have to deal with a dreadful 'spaghetti architecture.'
In this blog post, I’ll share some of the best practices you should follow to build a structured and scalable application architecture while avoiding turning your systems into a spaghetti bowl. This article is based on a recent Tech Talk on the same topic, Web and Mobile Architecture with Architecture Dashboard. For a more detailed discussion, I invite you to take a look.
At Stepsize, helping high-growth software companies measure and manage technical debt is our business. And this means we get to spend our days with some of the best engineering minds out there.
We've listened to their stories, and analysed hundreds of thousands of lines of their code and contextual data, to identify the signals of technical debt in all the noise. Following on from our broader definition of tech debt, in this article we'll share some examples of technical debt that we've spotted in the wild, to help you identify it in your own codebase — before it catches you off-guard.
In this post, I'll share with you how the best in our field make the business case for any given piece of tech debt.
Apply these lessons and you too will be able to understand which debt you should address first. They will help you unlock the resources you need by enabling you to convince your colleagues — especially senior management — that this is the right move.
The pressure has never been greater on developers: to move from legacy to modern infrastructure, to reduce inefficiencies, and create products that build customer satisfaction and increase revenue. Many enterprises are moving forward with a DevOps mindset, but in all their progress forward, they may be forgetting one thing, technical debt. Indeed, devs may be moving fast and breaking things, but never actually fixing them. In response, technical debt builds up, resulting in a downturn in engineering productivity and significant costs to an organization.
Earlier this year, Umser Mansoor did a small survey of developers for Codeahoy on technical debt. Out of 91 respondents, it found that 68% of developers said they work on products with high or very high amounts of tech debt. Technical debt costs companies $85bn annually, but it also has devastating impacts on engineering teams.
Debt is a complicated subject. The world often carries negative connotations with images of student loans, medical bills, or mortgage payments often coming to mind. In reality, though, some financial debt can actually help people.
The same thing is true with technical debt.
In simple words, technical debt is the bad engineering practice used intentionally or unintentionally while developing software which leads to adding up of complications to the existing code base which impacts overall maintainability and quality of the code. There could be innumerable reasons for such practices at the team or organizational level. Technical debt is insidious and arises in every codebase and every team sooner or later, impacting the overall agility of the Scrum team to respond to new changes.
No matter if you are developing a product from scratch or maintaining a product, if your team gets into some of the situations cited below then be sure to take some actions to correct your course before your agility becomes vulnerable.