Artur Wojnar’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

I laughed hard right after entering the room. During the call, My friend Arek told someone: “We’ll add it to tech debt.” It was years ago, and I probably heard that term for the first time. I was in my sarcastic heyday and thought it was a good joke. But Arek didn’t make a joke. He was serious about being in the planning meeting. Technical debt. Reread it. It even sounds silly. Ward Cunningham coined this term in 1992! 32 years ago. I was 7 years old at that time. Boyz II Men’s “End Of The Road” was the hottest musical single. That didn’t stand the mark of time, but technical debt did? Most of the projects at that time were digital transformation and automatisation. We had a clear split between business and IT. At that time, this metaphor could sound good enough to bridge the understanding. But now IT is a business, we should find a better language to discuss our issues. I believe that technical debt, as most people understand it, doesn't really exist. It's a convenient label that lets us acknowledge issues without actually addressing them. I tried to justify my bold claim in today’s #ArchitectureWeekly edition. See: https://lnkd.in/dibjPtn5 By labelling the low quality as technical debt, we postpone the real issue. We do not acknowledge that we made a trade-off. The term becomes a crutch, allowing us to feel okay about not addressing the underlying problem. It’s an easy excuse. We should stop that and make no excuses. Be accountable. The article is a longer rant, but I also tried to be proactive and gave the checklist with the questions to ask ourselves, our colleagues, and business people to make a proper tradeoff analysis that will bring us closer than hiding behind 32-year-old terms. Even by looking at Ward Cunningham's later recollection, it's clear (to me) that the tech debt metaphor wasn't meant to be a rotten compromise that required lower value. It was about delivering based on our best understanding of the current situation. That view may be flawed, but we should embrace it. The focus should be on the future. Not trying to measure or manage our past mistakes. We only see the outcome of our past choices if we made them; what’s more, they will be unrelated if we don’t need to make another decision based on them. We should do our homework. Accept the current state, ignore the sunk cost, and improve our design by properly analysing and showing adequate business arguments to our peers. What's Your Take?

Technical debt is like credit card debt. I was in Portland last Wednesday at an #24NTC session on technical debt. There were no slides, just discussions. What is technical debt? Technical debt is when a company takes an implementation shortcut to meet schedule, budget, or resource constraints.  And, it's a conscious decision because you intend to come back and fix it later, but that usually doesn't happen.  It is a very rare case when people do that. Like credit card debt, you can’t dodge it forever. Pay it down or face the music. Otherwise, you’ll end up declaring bankruptcy and starting anew. So you may be wondering… What are the consequences of technical debt? Here are the responses that I heard. 1. “Your system is down, impacting your brand and reputation.” 2. “Documentation is the first to get cut. As a result, you don’t have a history of the changes made and the reasons behind them.” 3. “You make incremental changes and create a Frankenstein.” If not checked, over time, you can accrue so much technical debt that your applications become sluggish and fragile. Type a Y or an N in the comments and let me know - is the term "technical debt" familiar to you? —- Hi, I’m Nichole and I help organizations resolve technical debt. If your websites or web applications need a tech makeover or fresh start, DM me to have a conversation. We can trade war stories and battle scars. #tech #technology #consulting #transformation #appdevelopment #webdevelopment #websitedevelopment

Technical drag. That's the term I prefer instead of "technical debt." The phrase "technical debt" was originally framing a strategy: I'll incur debt now to go faster, and I'll pay it back later. That's not how people tend to use the phrase now. Technical debt caught on to describe the on-going "interest payment" of a system that needs to be maintained. But it's used as expansively as: - it lacks documentation on how it works - it's written in a language no one of the team knows - it's written in a way I don't like Are those usages wrong? Probably not, but debt is a bad proxy to talk about those things. I think drag is better. I'm using drag in the sense of "adding a hood ornament to the car increases drag". Technical drag better describes the effect, because more things, even small changes, can increase drag and decrease the rate of flow—of movement of change—and does so directly proportional to the _square_ of the velocity. This difference helps place it in the cognitive space the tradeoffs: it doesn't matter that much if it's harder to change a system by 10% or even 100% in terms of real time: "what's another 2 hours of work to change something vs 200 hours to rewrite it?" However, if you're doing 100 hours of work per week in a system, then this choice to pay that down and get that time back makes more sense. So I'll keep using "technical debt" for talking about the choice in front of me, but after the decision made to do it, I'll be talking about how "it added to our technical drag".

Technical debt is sneaky. Just like credit card debt. Initially helpful, but it piles up before you know it. When you delay fixing code issues, you're borrowing time. But soon, you have to pay it back—often with hefty interest. Why does this happen? - Quick fixes overshadow long-term planning. - Pressure to deliver fast results pushes quality aside. - Neglected small debts accumulate into major setbacks. Consider a project where shortcuts were taken to meet deadlines. As new features roll out, these shortcuts become bottlenecks, requiring more effort to resolve than ever anticipated. How can we manage it? 1. Prioritize code quality—invest time in robust solutions. 2. Create a strategy for regular refactoring. 3. Allocate resources for paying down debt without disruption. Building sustainable software means balancing speed with quality. Start today. Evaluate your technical debt and plan to tackle it. What strategies have you used to manage technical debt? Share your insights!

Lessons from Behind the Keyboard: What is "technical debt?" The term "technical debt" is thrown around a lot by us techie types. There's not a perfect definition of what qualifies as technical debt, but at a high level it is the debt (both costs and extra work) that builds up when you prioritize speed over quality. In software development, sometimes you are forced to take "short cuts" in order to meet a deadline or deliver something within a budget. Is technical debt always a bad thing? As a coder, I find technical debt to be a terrible thing. I want anything I build to be as perfect as possible. But as a business person, my views on taking on "technical debt" are more complex. Working on software development projects for clients over the years, I have observed that many business decisions are about "trade-offs." Sometimes it make sense to take a technical shortcut in order test the waters on a feature, respond to an emergency, or keep short-term costs down. This is of course never ideal. But unless you have unlimited resources and time-- at some point it is bound to happen. The key: if you take on technical debt it should be intentional. As long business owners and coders (all together) review the risks vs rewards and are aware they are taking on tech debt for a good reason-- as bad as feels for programmers, for businesses there's a way to make tech debt into a good investment.

Runaway Tech Debt I was recently listening to advice from Financial Guru Dave Ramsey about financial debt and how it can control us. The thought occurred to me that this is very much a factor in software development when we have tech debt. The problem with tech debt is that many of us simply accept it and toss it into a bucket without considering the cost. This applies to missing or incorrect documentation, slow-running queries, clunky interfaces, and so much more. Yes, we can get away with technical debt for a bit here and there when we have to hit a deadline. However, those little things can add up. The worst part about those "little things" is that they are small thieves of time and quality that can be hard to measure. Thus, we allow them to be a part of the experience with that codebase or application. For example, how often do you hear a user complain about a solution but then brush it off like that is just how things are? The idea behind technical debt is that we have a task we should do, but we kick it down the road instead. If this was not a task we should be ding it would not be technical debt. That is no different from getting an oil change for your car or cleaning air filters. We have a period of time where we can push those tasks off, but eventually they can grow to an emergency situation that must be immediately addressed. Just like we need to keep track of debt in general, technical debt should be reviewed regularly and even avoided where we can.

Drowning in technical debt? Don't let it sink your ship! Our blog post reveals 8 effective strategies to tackle it head-on. 👉 https://zurl.co/0O7Q #TechnicalDebt #BusinessTips #MSPs

Drowning in technical debt? Don't let it sink your ship! Our blog post reveals 8 effective strategies to tackle it head-on. 👉 https://zurl.co/0O7Q #TechnicalDebt #BusinessTips #MSPs

Lessons from Behind the Keyboard: What is "technical debt?" The term "technical debt" is thrown around a lot by us techie types. There's not a perfect definition of what qualifies as technical debt, but at a high level it is the debt (both costs and extra work) that builds up when you prioritize speed over quality. In software development, sometimes you are forced to take "short cuts" in order to meet a deadline or deliver something within a budget. At some point it is debt you will have to pay off. Is technical debt always a bad thing? As a coder, I find technical debt to be a terrible thing. I want anything I build to be as perfect as possible. But as a business person, my views on taking on "technical debt" are more complex. Working on software development projects for clients over the years, I have observed that many business decisions are about "trade-offs." Sometimes it make sense to take a technical shortcut in order test the waters on a feature, respond to an emergency, or keep short-term costs down. This is of course never ideal. But unless you have unlimited resources and time-- at some point it is bound to happen. The key: if you take on technical debt it should be intentional. As long business owners and coders (all together) review the risks vs rewards and are aware they are taking on tech debt for a good reason-- as bad as feels for programmers, for businesses there's a way to make tech debt into a good investment.