Varun Tayur’s Post

Highlight notes: "Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release" "So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt." "but decide to go "quick and dirty" because they think they can't afford the time required to write clean code" "My view is this kind of debt is inevitable and thus should be expected. Even the best teams will have debt to deal with as a project goes on - even more reason not to recklessly" "reposted on 19 Nov 2014" from the good Martin Follower https://lnkd.in/de7sS7Tz #techdeb #coding #team #cleancode

Is debt good or bad? Yes. Financial debt is a powerful tool. Used well, it can enable the impossible and contribute to wealth generation. Used poorly, it can destroy it. Similarly, with #techdebt, knowingly—or unknowingly—leaving some concerns for another day may be the right thing to do. But we must intentionally manage that. In this blog post I consider three parallels between financial and technical debt: 1. Know your interest rates 2. Don't over-extend yourself 3. You have to make regular payments It's a 2 minute read. I'd love to hear in the comments what you think. https://lnkd.in/gNBvNWnM #engineeringleadership #technicaldebt

Financial Debt, Credit Card Debt, Education Loan Debt, Medical Debt, Technical Debt. Crux of the matter is whether it is Good debt or Bad debt. "Good tech debt can be described as the debt incurred to foster growth and innovation without significantly affecting your business. Conversely, bad software debt hinders business performance as it impedes the innovation, agility, and growth your software underpins, whether developed recently or years ago." Addressing the matter starts with the how ? Read about the the 8% approach....vis a vis the capability of "mapping" the Software landscape Worth a read , courtesy of author Vincent Delaroche

"Technical debt is debt — you take shortcuts now, but you pay the price later with interest." But that metaphor is broken, here's why: 🤔 When you take on financial debt, the cost is clear. You know the interest rate, and you can predict how much you’ll owe in the end. 📈 Technical debt isn’t like that. It’s more like hidden friction that slows down your development over time. The impact isn’t predictable — it accumulates unpredictably and compounds in ways you can’t fully anticipate. As it gets worse, so does the time required to fix it. The truth is, tech debt is inevitable in any fast-paced environment. The key isn’t to avoid it but to keep it in check: 1. Identify your weak spots: Always know where your subpar code lives. Keep a clear map of your known friction points. 🗺️ 2. Track delivery times: The only reliable metric for tech debt is how much it’s slowing you down. Establish an average throughput you’re happy with and use deviations from that to gauge the impact of your debt. ⏲️ 3. Apply the Boy Scout Rule: Whenever you touch a piece of code, leave it a bit cleaner than you found it — but only where you’re already making changes. Don't get bogged down refactoring unrelated parts. It’s about incremental improvement, not perfection. 🧹 At the end of the day, tech debt is only a problem if it’s affecting your ability to deliver. Optimize for speed, but never lose sight of where the friction is creeping in. 🚀 --- 🔧 Transforming Business Challenges into Scalable, Impact-Driven Solutions 💡 👉 If you're facing challenges with tech debt or optimizing your development process, let's connect! I'd love to hear your thoughts and exchange insights. #TechDebt #CTO #CleanCode #TechLeadership

If you are serious about legacy modernization, the first thing you should do is to shift the conversation away from the topic of technical debt. Yes, you read it right. You should stop talking about technical debt, or if you must talk about it, do it when you want to take a break from interesting conversations. Why? At least two larger reasons. 1. Debt is a useful economic concept, but if you are interested in creating profit you certainly should not talk only about debt. Instead you should talk about creating value. You might want to use debt sometimes, but at most as a supporting tool to how you create value. 2. Technical debt is a negative metaphor. The best case scenario is to not have debt. That's rarely something to get excited about. I can still remember the last years of the Romanian communist regime when they decided to pay off the country's external debt. I was young at the time, but I could understand quite well that nobody around me felt any enthusiasm when the debt was being paid. Technical debt dominates the conversation between business and technology today. It is useful in certain situations, like the one that Ward Cunningham was in when he first coined it. But the way it is typically used (and especially all the work pretending to measure it no less) is detrimental. If you position technology as debt creator, do not wonder if the tech unit is treated as a cost center. Instead, your goal should be to create value with technology, not decrease debt. That's what your conversation should be about.

I think many people in the software industry make the mistake of viewing tech debt like a loan in deferral. They decide to add to their debt assuming there is no short term cost, but one day they will have to start paying it down (or declare bankruptcy with a huge rewrite). A more accurate analogy would compare your tech debt to credit card debt. You immediately start paying for this debt. The minimum payment would barely chip away at the interest accruing. You pay that cost in your project with every feature. The tech debt you add today makes the feature you add tomorrow more difficult. Every work item you take on without addressing the debt will be more difficult, and will likely add to the debt itself. With both analogies, a common end result is crippling debt that grinds your progress to a halt. However, the former analogy assumes that you are making quick progress, when that simply isn't the case. "The only way to go fast, is to go well." - Robert C. Martin

Tech debt is the most peculiar kind of debt I've ever seen. Very different from a financial debt. It's fascinating how it interacts with the world: 1. We're used to taking it daily, in small portions. It's surprisingly easy to take. 2. Other people can take this kind of debt on behalf of us/our team, and it directly impacts us. Paying the debt by other people, though, is harder. 3. In happy cases, you don't have to pay the debt because e. g. the piece of architecture where you took it can get deprecated/removed. Or it "just works", and there's no need to realize we have the debt there. 4. The amount of interest is rarely known up front, and it can skyrocket within days. Usually paying it off is many times more expensive, however we quantify it. 5. A piece of tech debt in one place can force us to take another portion of debt in another place. 6. It's almost impossible to have no tech debt, like "pay cash". Otherwise, the product could die. Do you have any interesting stories or lessons learned about tech debt in your projects that you could share? 😊

If you read only one thing about Tech Debt today, make it this. It satisfies the challenging analogy between Financial Debt, Leverage and Tech Debt. https://lnkd.in/e6-aP4vm BTW< I found this in a gold mine of Martin Fowler articles https://lnkd.in/edjXdMVe

3 types of "high interest" technical debt to tackle first Per my earlier post, technical debt is not always a short-term problem. But all debt is not created equal! Here's my assessment of a few categories that will drain you fast enough that you should prioritize resolving it quickly. 1. Daily drama. The tax you pay to your technical debt is influenced by how many people touch it, how often they touch it, and how much it hurts them each time. At the very top of this hierarchy you find issues that infect the daily practice of developing code. - Sometimes the build fails and nobody knows why. - Flaky unit tests have to be rerun or get ignored. - The push to prod never succeeds the first time. These undermine all progress. Fix them first. 2. API debt Bad APIs are a double whammy. First, they're *visible*: your customers see and interact with a bad API, not just your team. And second, API usage grows over time. The hole only gets deeper the longer you leave it unaddressed. Even if you don't have the time to fully deprecate and eliminate the bad version, introducing a better version ASAP can help. With a better alternative, the problem will be more inclined to shrink instead of grow if left alone. 3. Blinders. Ever heard, "we'll add monitoring later"? Debt that keeps you blind to how your systems are operating is insidious. If you don't know whether the system is working, you'll only find out it's broken when someone else (like a customer) tells you--which automatically makes every incident more severe. Perpetual high-octane incident response will burn through your team's morale and goodwill quickly. What other categories of debt have you noticed to cause the biggest long-term pain? Let me know in the comments!

👉 TECHNICAL DEBT ERRATUM👈 Yesterday, I published a post about technical debt, and Oskar Dudycz (also yesterday) published his take on that. Much longer and more profound. You see, it is all about perception. We both talked more or less about the same thing, but I realized if we replaced the "tech debt" with "trade-off" in my post, then the whole thing would become more understandable. Like this sentence: "Thus, so-called “technical debt” is a glue that lets you meet the ends. You make it on purpose." ...sounds better this way: "Thus, trade-offs are a glue that lets you meet the ends. You make it on purpose." I don't want you to think I justify doing shitty implementation because of deadlines. We should make the best decisions at the moment of taking those. My yesterday's take was what it means to make a decision that is not always what a team commonly thinks is the best technical solution at the moment. It's a matter of perspective and being responsible for the common good, which is the value of the project. https://lnkd.in/dWjhB58r https://lnkd.in/dgbAXQPY #softwarearchitecture