TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

We sound like idiots when we talk about technical debt

130 点作者 seekayel超过 3 年前

39 条评论

wokwokwok超过 3 年前
Controversial idea:<p>Technical debt is something that &#x27;business users&#x27; don&#x27;t need to or want to care about.<p>If you&#x27;re having conversations about technical debt, you&#x27;ve messed up, and you will continue to have unsatisfactory outcomes until you stop doing so.<p>You can&#x27;t tell people; here is a dial, you can pick &#x27;fast and you&#x27;re screwed later&#x27; or &#x27;slow and careful now&#x27;. You&#x27;re setting yourself up for failure; they <i>cannot</i> pick &#x27;slow and careful&#x27;, because that&#x27;s not their job; their job is to quickly deliver value&#x2F;outcomes&#x2F;whatever.<p>Almost no one has a job of &#x27;go do this really slowly and carefully&#x27;.<p>They will always pick fast, and it&#x27;s your problem later.<p>So... don&#x27;t do that. Instead, say: this is how long it will take to do.<p>Not &quot;if we rush we could probably do it in...&quot;; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have &#x27;skin in the game&#x27;?<p>Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.<p>Then, do enough of a good job so you can continue to deliver value in the future.<p>That&#x27;s literally your job.<p>Doing a rubbish job as quickly as you can is not your job. Not ever.<p>You cannot abrogate responsibility for doing your job properly by saying &quot;but I was told to do this&quot;, if you <i>literally gave them the choice</i> of A or B, where one of those options was &quot;you have to pick this one, and it lets me get away with doing a rubbish job of it&quot;.<p>That&#x27;s <i>YOU</i> choosing to do a rubbish job.<p>...and to be fair, yeah, there are situations where someone will come and tell you &quot;no, do it now&quot;, and that&#x27;s what you have to do... but you also have to come and clean up afterwards. Not because you&#x27;re told to, explicitly, because... it&#x27;s your job.
评论 #30286398 未加载
评论 #30286160 未加载
评论 #30285087 未加载
评论 #30284999 未加载
评论 #30286959 未加载
评论 #30285063 未加载
评论 #30288240 未加载
评论 #30284983 未加载
评论 #30284979 未加载
评论 #30284951 未加载
评论 #30287095 未加载
评论 #30286644 未加载
评论 #30287140 未加载
评论 #30289855 未加载
评论 #30285003 未加载
评论 #30284977 未加载
评论 #30285192 未加载
评论 #30290280 未加载
评论 #30286079 未加载
评论 #30286661 未加载
评论 #30286100 未加载
hermannj314超过 3 年前
If the contractor finds asbestos, he&#x27;s allowed to quote me more to do the work I hired him for.<p>If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work.<p>When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are renegotiated.<p>Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has &#x27;technical debt&#x27; too.<p>It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn&#x27;t there because &#x27;its not the customers&#x27;s problem&#x27;
评论 #30293042 未加载
评论 #30288398 未加载
评论 #30287086 未加载
评论 #30298422 未加载
hobs超过 3 年前
People saying &quot;its on you&quot; and &quot;has your boss ever reviewed the code?&quot; have not had varied enough experiences.<p>Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you&#x27;re fired?<p>I have in fact had my commits gleaned by my boss, told me &quot;no, we&#x27;re not shipping these 10 lines of code because that goes too far and not what I asked&quot; and then refused to accept the pull request because he had control.<p>Just because YOU have never been in a situation where YOU didn&#x27;t have control over the creation of technical debt doesn&#x27;t mean its just some magical thing you can fix and change by saying the right words, don&#x27;t be naive.
评论 #30285037 未加载
评论 #30290233 未加载
jimbokun超过 3 年前
&gt; The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market.<p>Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be.<p>Time to market is also absolutely impacted by technical debt, for the same reasons.<p>Describing this to company leaders in ways they understand is pretty straight forward.<p>&quot;If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward.&quot;<p>Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.
评论 #30288635 未加载
tristor超过 3 年前
I think the metaphor for technical debt is leaky, but I don&#x27;t think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to &quot;rushing things&quot;, but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I&#x27;ve seen technical debt addressed successfully in a fairly long (~18 years) career:<p>1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.<p>2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it&#x27;s on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.
adrianN超过 3 年前
Technical debt and its costs are extremely hard to quantify and saying things like &quot;with 3-6 weeks of engineering time we can cut failures in half&quot; is just inventing numbers to get what you want.
评论 #30284946 未加载
评论 #30284817 未加载
评论 #30284889 未加载
评论 #30284813 未加载
评论 #30284787 未加载
EarthLaunch超过 3 年前
Usually it&#x27;s hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don&#x27;t pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money.<p>Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It&#x27;s relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn&#x27;t learned about financial instruments.<p>King: We need to raise an army.<p>Duke: Okay, but we&#x27;re out of money. We&#x27;d have to borrow more.<p>King: Are we able to borrow money for it?<p>Duke: Yes, but our debts are racking up, and there could be future consequences.<p>King: Sounds like we can borrow money, do it.
评论 #30284861 未加载
评论 #30284906 未加载
choeger超过 3 年前
Maintenance also has a second aspect: Bitrot.<p>Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don&#x27;t control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem.<p>The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: &quot;We won&#x27;t be able to ship&#x2F;develop after day X because big OSS project Y deprecated our version&quot; (think CentOS repository deletion).<p>It is our job to keep an eye on this and report it in the terms management understands: &quot;We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities.&quot;
评论 #30285218 未加载
k__超过 3 年前
Usually, the discussion goes the other way around.<p>Product is pissed because delivery is stagnated and that&#x27;s because of technical debt.<p>Product: We need that change for Big Co.<p>Techie: Okay, that takes two weeks.<p>Product: Two weeks? For such a small change??<p>Techie: Yes, because we are drowing in technical debt and you&#x27;re priorizing features and not maintanence.<p>Also, usually techies don&#x27;t care.<p>Why? Because it&#x27;s always good to have an excuse to work slower.
评论 #30284773 未加载
评论 #30286871 未加载
评论 #30284771 未加载
catlifeonmars超过 3 年前
Speculation ahead:<p>One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).
评论 #30286530 未加载
评论 #30288742 未加载
评论 #30286348 未加载
corry超过 3 年前
One of the things I struggle with in the perennial conversations about technical debt at startups is how to account for the fact that the future in not known with certainty: i.e. circumstances can change that render very good and &#x27;worth-it&#x27; (but expensive) technical decisions obsolete in future.<p>My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to &#x27;do it right&#x27; vs &#x27;do it fast&#x27;, since they believe that EVEN IF it&#x27;s &#x27;right&#x27; today, it probably won&#x27;t be &#x27;right&#x27; tomorrow and we&#x27;ll have to rewrite&#x2F;re-do&#x2F;refactor to accommodate the new paradigm&#x2F;circumstances.<p>Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. &quot;prepaying&quot; the cost of fixing the future problem.
cweagans超过 3 年前
IMO: software engineers have a professional responsibility to mitigate technical debt (among other things).<p>Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit.<p>Software engineers should not _ask permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there&#x27;s no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them.<p>There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don&#x27;t just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.
评论 #30290105 未加载
trunnell超过 3 年前
A &quot;culture of approvals&quot; is one root cause of this situation. Something needs to be done, but instead of doing it an engineer asks someone else for approval and doesn&#x27;t receive it. Healthy teams don&#x27;t work that way.<p>In a healthy team, engineers are <i>responsible</i> for the health of the system.<p>In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the <i>relative priority</i> of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.
syntaxfree超过 3 年前
This isn’t that complicated.<p>Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former.<p>But financial debt is authorized by corporate finance, which is empowered to do so by the C-suite and implicitly by shareholders. Whereas technical debt is created at ones own risk by the Individual Contributor, who didn’t ask the shareholders if they liked the trade off.
phendrenad2超过 3 年前
We sound like idiots because we treat businesspeople like idiots. We parrot a definition of tech debt we got from a blog post. The whole analogy to debt is a hand-wavy joke of a definition anyway. It&#x27;s not debt, it&#x27;s a liability that&#x27;s depreciating the assets of the company intellectual property.<p>The only reason it looks like debt is because it compounds, which is ironically something people don&#x27;t really focus on when discussing it with management. People don&#x27;t want to look incompetent so they say &quot;Feature X took 3x as long as it should have, because we had some tech debt&quot;. It&#x27;s implied that the tech debt is resolved. But in most cases the reality is, the time was spent just working around the tech debt, and the tech debt is <i>not</i> resolved. And now you&#x27;ve entrenched even more workarounds and hacks that will make things worse. Compound interest baby.
dasil003超过 3 年前
Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater.<p>The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain.<p>Of course, all analogies are flawed, and the devil is always in the details. Over time &quot;technical debt&quot; has been used to describe all manner of problems which don&#x27;t really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc.<p>What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you&#x27;re sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can&#x27;t just cry &quot;technical debt&quot; at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80&#x2F;20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.
trwhite超过 3 年前
The metric that you use to measure technical debt is &quot;the time it takes to build new features over time&quot;. If that line on your graph is going up, you have a problem.
评论 #30284987 未加载
评论 #30285091 未加载
评论 #30284978 未加载
评论 #30284969 未加载
cestith超过 3 年前
Perhaps technical debt is the wrong term to use with nontechnical people, who tend to startle that they aren&#x27;t even meant to understand so soon as the &quot;tech&quot; part comes out of someone&#x27;s mouth.<p>If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we&#x27;ve taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.
评论 #30292568 未加载
Tretio超过 3 年前
Stop talking to business about technical debt.<p>Stop creating technical debt.<p>No one ever asked me why in particular something took 3 days. I don&#x27;t explain to someone that I wrote unit tests and no manager told me not to write tests.<p>Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written?<p>If you accept technical debt it&#x27;s the development teams fault.<p>And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.<p>Instead lern to talk back: &quot;oh you promised our customer that this feature will be ready tomorrow? I&#x27;m seeing a big risk in this as there are still issues we haven&#x27;t figured out, you might want to manage their expectation.&quot;<p>&quot;Ah sry I can&#x27;t work longer today I already have a reservation&quot;<p>&quot;On the weekend? Mh I booked a hotel already&quot;<p>&quot;How long this takes? Mh let&#x27;s see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update.&quot;<p>&quot;I can prioritize your new request but I will talk to x to tell him that his task will be delayed.&quot;<p>&quot;Didn&#x27;t you promise customer x feature y already? Should I stop working on y to start with your new request?&quot;
评论 #30284968 未加载
评论 #30284895 未加载
评论 #30284894 未加载
评论 #30284907 未加载
andrew_超过 3 年前
This reads to me as an incredibly reductive take on a real-world problem, offloading blame&#x2F;responsibility to engineers to properly frame something which very few engineers fully comprehend or can intelligently convey. I understand the author is trying to teach how to frame it, but it still requires experience and skill that I&#x27;ve seen very little of during my career in all but the most experienced or talented engineers.<p>Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they&#x27;ll understand.<p>&quot;We&quot; the engineers don&#x27;t sound like idiots - &quot;we&#x27;re&quot; being literal, which is all &quot;our&quot; job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.
commandlinefan超过 3 年前
What&#x27;s really frustrating is that technical debt leads to real problems. It&#x27;s just that these problems have been so pervasive for so long that everybody just accepts them like a bad smell that you don&#x27;t really notice. Technical debt is the underlying root of:<p><pre><code> - you said you fixed this problem but I&#x27;m still seeing it - you fixed this problem but you created a new one - we can&#x27;t deploy a fix for this problem right away because we have to certify the whole monolithic mess first - testing this fix takes an hour to coordinate </code></pre> These <i>are</i> problems that business owners should care about, but they&#x27;ve just come to accept that this is the reality of software development.
chillage超过 3 年前
I use a couple pretty simple measures to get the technical debt idea across, with the numbers variable:<p>&quot;if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%&quot;<p>Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.
mberning超过 3 年前
You have to tie it to something they want or need.<p>They “need” to be on the latest version -&gt; upgrading versions takes a long time and is prone to error -&gt; the process would be infinitely easier with a robust test suite -&gt; we never prioritized automated testing which is a tech debt which we are now paying interest on in the form of being on extremely old versions of a product.
0xbadcafebee超过 3 年前
If you have a car, and drive it 100 miles every day, and keep driving it for years, it will seem like everything is fine. Until one day the engine seizes up and it unexpectedly costs you $5,000 to fix, because you never changed the oil or did any other maintenance. There was never any apparent, obvious reason that maintenance was required. But no regular maintenance <i>does</i> lead to unexpected high costs.<p>It is critical that technical people have data to back up their claims that maintenance is needed. We need to identify exactly what each piece of tech debt is, how much work is needed to remediate it, and what the business cost of not remediating it is. Otherwise the business has literally zero idea what it will cost them <i>not</i> to do maintenance. This is an expected part of professional software engineering in a business. If you are not gathering this data and presenting it to leadership, do not expect them to take you seriously. It is up to you to prove your case.
adityaathalye超过 3 年前
Hah :) I&#x27;ve also had a recent blog-post length thought about this entitled:<p>&quot;Technical Debt is really Software Debt. And it’s a AAA-rated CDO.&quot; <a href="https:&#x2F;&#x2F;www.evalapply.org&#x2F;posts&#x2F;software-debt" rel="nofollow">https:&#x2F;&#x2F;www.evalapply.org&#x2F;posts&#x2F;software-debt</a><p>Context:<p>&gt; I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.<p>&gt; One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge.<p>(More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :)<p>Edit: add some context from the blog post.
scotty79超过 3 年前
If Big Corp co is paying per man-hour doing a thing in a week that could be done in a day is actually huge win from the point of view of a business person.<p>Everything should be done as slow as possible as long as client isn&#x27;t annoyed enough to change providers.<p>Business people both at your company and at Big Corp co customer benefit from keeping things as they are for as long as possible. They keep getting paid for as long as the project lasts. But when the project finishes, a lot can go wrong. It might turn out that it was completely unnecessary or that it doesn&#x27;t solve the problem it was supposed to solve or that any given business person no longer has any utility for the respective companies. Basically a lot of trouble. So technical debt might be something business people actually silently treasure.
gilbetron超过 3 年前
I get the using &quot;debt&quot; is an attempt to make it understandable to financial-oriented people, but I think it is a double-edged sword. You have to pay off financial debt, you don&#x27;t have to pay off technical debt. I think using &quot;technical friction&quot; is a better approach. You are increasing the cost of future projects. &quot;Cutting corners on that will increase the cost of all future efforts by 10%&quot;. That is more impactful and conveys the situation better. Likewise, &quot;well, we cut corners here last year to get the demo made, so now this project takes 25% more time.&quot;<p>Even if we SWAG the percentages (which, guess what, financial-oriented people do all the time!), it lets Product Owners and Managers make better decisions.
评论 #30291884 未加载
CyberRabbi超过 3 年前
Great post. One of the major problems is that software engineering is saturated with green devs who recently transitioned from hobbyist coding and don’t fully understand the responsibilities of being a professional. Hobbyist projects are rarely held to external constraints. Usually when the hobbyist dislikes the code he has thus far written, he will rewrite it instead of iterating on it because he has that luxury since nothing depends on his project. Unfortunately in the real world, we have to consider other factors aside from what the author prefers to work on.<p>This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.
renewiltord超过 3 年前
Tech debt is a thought terminating cliche. Progress is possible more easily if we talk in a Markov fashion: under present circumstances, to get X, we need to do Y.<p>The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision.<p>Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”
selimnairb超过 3 年前
Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits of dealing with technical debt before it is too late.
评论 #30284833 未加载
Tarucho超过 3 年前
Part of the problem is the twisted naming we are using for development related things. Tech debt, ceremonies, sprints, masters, squads, etc.<p>Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.
amznbyebyebye超过 3 年前
One trick we use is to just bake it in as part of a new medium to large size feature. Or if product is swamped with stakeholder management related stuff, we leave a gap sprint for all these tech debt related things. Another thing we do is have a dedicated platform team whose main charter is to work on general improvements inclusive of tech debt reduction.
andi999超过 3 年前
I think the term &#x27;technical debt&#x27; is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of &#x27;financial debt&#x27;. Why not call it &#x27;we have been cutting corners in the software architecture&#x27;; I think people will understand that analogy better.
评论 #30284974 未加载
评论 #30285055 未加载
评论 #30284845 未加载
Jtsummers超过 3 年前
Techie: We are drowning in technical debt!<p>Business person: Oh really! What is it costing us?<p>Correct response:<p>Techie: Every new release is taking longer and longer to complete. When we don&#x27;t give ourselves the time, we have more bugs that are driving away customers.<p>Time is money, business people understand that. Address that aspect of the issue.
thinkharderdev超过 3 年前
This article seemed pretty incoherent:<p>&gt; Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value.<p>And then literally two sentences later:<p>&gt; They care about time to market.
评论 #30284902 未加载
tcgv超过 3 年前
Techincal debt is a typicall long term problem without a short term solution. Product managers are biased towards delivering short term value incrementally, and don&#x27;t like anything that slows down the value delivery pipeline.
shakezula超过 3 年前
Agree with the headline. I&#x27;ve always preferred to use code as mass as the analogy, because inertia, friction, etc... are more applicable to the situation than money and debt, imo.
dqpb超过 3 年前
Maybe supply chain is a better analogy than debt.<p>Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.
namelessoracle超过 3 年前
My experience dealing with product managers is you have to phrase it one of 2 ways.<p>If you know your taking technical debt, explain to them that its like a credit card, but instead of money its time, and we can go ahead and swipe it, but you will eventually have to pay it with interest, and the cost you are paying is every future story is gonna be a little bit slower until things that should be able to get done in a week take a month. ( I have seen this happen personally with a project and the whole thing had to get completely rewritten)<p>If its unforeseen technical debt, dont call it that. Call it foundational work. Tell them the foundations were not set in a way to support X or Y feature so we need to change&#x2F;update the foundations to get them the feature they want. This seems to work best. Don&#x27;t even tell them there is a hack or duct tape solution, bring up the foundational piece first. If business needs has a requirement that it gets out faster, then transition to the credit card analogy and explain they are now swiping the credit card and whenever they complain about velocity use this an example.<p>The biggest problem is that product managers typically move on or get promoted by the time the technical debt they incurred causes bankruptcy. And fixing that usually tends to involve a rewrite which will have new flavors of technical debt (especially when its in new language), with a new product manager selling their &quot;V2 solution&quot; as so much better. (and successful delivery of that seems to involve them getting promoted or moving to another place soon after)