Technical debt is not debt; it’s not even technical

127 点作者 selphy1将近 4 年前

46 条评论

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this:"Technical debt is the burden that implementation choices may place on future development."Nothing in the article leads me to think that this is either incoherent or irrelevant.With regard to its coherence, I say that it is empirically verified: it actually happens!The claim that it is not technical because it has consequences beyond the technical is a non-sequitur. Just about everything we do that is 'technical' has implications and consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that. The root cause of a problem and its broad consequences are separable concerns.This formulation avoids the objection that its only debt if it is paid back in the same form as it taken out, but that was a tendentious claim anyway - it is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt. If we are going to be pedantic, the author might as well say that technical debt is not debt because it is not an exchange of money. Arguing over dictionary definitions is not going to lead to anything useful in this matter.

评论 #28007663 未加载

评论 #28008721 未加载

评论 #28007938 未加载

评论 #28008378 未加载

评论 #28007645 未加载

评论 #28010192 未加载

评论 #28009537 未加载

评论 #28012519 未加载

评论 #28008455 未加载

评论 #28009482 未加载

评论 #28007620 未加载

charles_f将近 4 年前

A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong".B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at some point and uses this to say "it's not technical because it's business". But it is technical because, well, it is issues with your technology. That you borrowed on your tech stack for business reasons doesn't make it less technicalC) ironically I'm arguing on semantics because I find the title to be semantically wrong. In fact I largely agree with the point of view, tech debt is the result of a strategy, be it that you want speed or low cost. Sometimes it makes sense for the business, and as long as the strategy is conscious and explained, and that we're clear with the consequences, I'm fine with it. In my experience most of the time it's not an assumed strategy and we dont want to deal with the consequences.

评论 #28005553 未加载

评论 #28005475 未加载

theamk将近 4 年前

I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title.Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept"However, there are generally accepted meanings of the those terms for the technical debt:- The "principal" is how many things is wrong with the code. It could be measured in features ("We need to implement unit tests and database layer to clear technical debt") or in time ("it will take 6 FTE-months to clear our technical debt")- While "interest rate" is rarly used, "interest payment" is common -- this is extra time spent implementing the new feature. One can say: "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"- Not all debt has fixed term. "revolving debt", like a credit card, has no term at all. Technical debt is like that as well.(Of course getting the actual values for "pricipal" and "interest payment" is very hard and no two people are likely produce the same estimate for them. But even if don't know the values it does not change the fact the the terms are defined well -- so this is very much a "debt")As for "not even technical" part: I am going to argue that everything indirectly affects competitiveness, costs, customer satisfaction etc.. A leaking roof will decrease morale, decrease development speed and can even kill the company. Judging by consequences does not really bring anything useful to the table, so if you want to qualify the term, let's use originating action. "Technical debt" if we don't have any tests. "Financial debt" if we took money from the bank. "Organizational debt" if we are not creating the positions we need, and so on...

评论 #28005669 未加载

评论 #27994451 未加载

评论 #28005615 未加载

评论 #28030776 未加载

评论 #28005244 未加载

lionkor将近 4 年前

Technical debt is when you effectively borrow your future self's time and effort by taking a shortcut now that your future self has to work for to pay for it.It is literally a debt. I dont know what the article is trying to say, it sounds to me like something my boss would say after a 2 hour meeting in a delirious caffeinated state, but thats probably just because I am not familiar with the corporate use of the term "technical debt".

评论 #28013856 未加载

lmm将近 4 年前

The idea that debt has a specific and clearly-understood principal, term, and interest rate is a very narrow corporate-finance perspective. Many forms of debt in many cultures do not work like that (consider the notion of a "life debt"); you have a fuzzy sense that so-and-so owes so-and-so, but no specifics about exactly what or how it would take to repay that.Technical debt is not corporate debt but it is debt. The metaphor succeeds mostly because it's accurate.

pdimitar将近 4 年前

> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense.This really is NOT how you start an article. You only come across as needlessly assertive and arrogant.> Nobody explained technical debt; we assumed it was a fundamental property of the work.Total BS. Literally every manager I ever addressed in a sentence where "technical debt" was mentioned did question what exactly it is and why do we need to address and "repay" it. Where is the author of the article living? Not with us the programmers here on the ground, that's for sure.> Now, one major concern in academia is rigor.Ah, so now it's about academia and its definition. I'll cut him a deal. Bring your academics to my former customers and see if they can override management's idea of a technical debt. Succeed 5 times and then I'll bow to you and accept your definition. Until then you're just an annoyance like that guy on parties who is always going around telling people "well ACTUALLY you are using the wrong term".Doesn't matter what the dictionary says, people. It matters what most of the people think a word means. It matters what most of the people do when faced with the word. Why is this so hard to accept for many?--No, I haven't read the entire article. It smells of intellectual elitism and arrogance a mile away. The author must work on his tone.Technical debt, whatever your definition of it is, is still a natural property of tight schedules. That's it. We can all go home now.I wouldn't expect an academic to understand realities of schedules and budgets though.

评论 #28007216 未加载

评论 #28005898 未加载

dub将近 4 年前

Much of the time "technical debt" seems to be a euphemism for bad engineeringThe leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt"In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our business strategy all along.

评论 #28005735 未加载

评论 #28005815 未加载

评论 #28005770 未加载

xondono将近 4 年前

The argument is a little nonsensical.1. Is "technical debt" debt: If it walks like a duck...Not all debt is in the form of retail loans. Leaving a "IOU" note where someones lunch was, is a form of debt (a very dangerous one). Good luck trying to find out your interest rate in advance.2. Is "technical debt" technical: If we follow the author's logic, I guess now financial debt is not financial. Financial debt will also affect:<pre><code> - Competitiveness by slowing/speeding up new product development. - Costs (short-term decrease/long-term increases in development cycles) - Customer satisfaction - Whether a company can survive </code></pre> That's the point altogether, "technical debt" behaves in similar ways to financial debt.

AlbertCory将近 4 年前

I am deeply, deeply cynical about the notion of "technical debt." Why?Because it is inextricably tied to career ambitions. There is no promotion benefit to just "paying back" a small debt by fixing some kluge, while there is enormous benefit to leading a rewrite.Furthermore, once a rewrite is in play, the temptation to "just fix" a bunch of other things and add some new features that were hitherto impossible is irresistible. Perhaps the debt repayment gets added to Version N+1.You can say "oh, it doesn't have to be that way" and point to some glorious time when it wasn't, but in my experience, at least, it always is.

评论 #28010100 未加载

Accacin将近 4 年前

We can discuss meaning all you want, but I'll still get my managers asking me to write code quickly now and take some shortcuts, and telling me to write a "Tech Debt" ticket to fix it in the future.Spoiler, we never have time.

dktoao将近 4 年前

I work for a large computer hardware company who I consider to have crippling amount of unchecked technical debt (with no payment plan). Recently I managed to ask the CEO a question in an all-hands meeting. More or less:"What are your thoughts on managing technical debt across the organization?".His response:"I don't know what this technical debt you refer to is". Then he proceeded to answer the question as if I had asked about financial debt. This is the same person that allegedly said "Coding isn't hard, it's just typing!" according to some of the graybeard sources that worked with him when he was still a technical contributor.I agree with the premise of this article that top decision makers at a company need to be familiar with and actively monitor technical debt (or whatever you want to call it). It can have disastrous consequences for the company. I see it every day.

评论 #28010136 未加载

jpswade将近 4 年前

Technical debt implies that it is a technical decision, when mostly it’s a business one.Debt has a negative connotation, where as it’s more like a mortgage.I always wonder if there’s an equivalent term in manufacturing.

评论 #28007135 未加载

评论 #28005760 未加载

spottybanana将近 4 年前

I think the whole term "technical debt" has developed as a part of business and technical team negotiations. The technical team prefers to improve their own job comfort, doing tasks that make their job more comfortable and stress-free, but doesn't really add business value in terms of revenue and profit. The business side isn't aligned against this work, but their priorities are on the other side. "Technical debt" is a great term from negotiation viewpoint, because for clueless business leaders it gives the impression that the tech team is paying debt when it is doing this low-risk low-reward activity, when it actually isn't.

gilbetron将近 4 年前

I hate the term "tech debt", although I appreciate that it is a way to communicate with non-technical decision makers. It isn't debt, we don't have to pay it off.I consider it a coefficient of development friction that must be managed to be an appropriate level for your strategic (business and technical and other) goals.You want it as low as possible, but bringing it that low costs development effort that could be used on other efforts. Too high and simple changes take days and steals from productive work.Greenfield development has a near-zero coefficient, which is why it is so fun :)

评论 #28008104 未加载

评论 #28007813 未加载

IshKebab将近 4 年前

This is silly. Debt doesn't just have to be monetary. Or can we no longer say "I am in your debt" because we can't accurately estimate a monetary amount for that debt?

评论 #28005469 未加载

resters将近 4 年前

Startups take on a lot of types of debt. Sometimes they hire less experienced people, you could call that HR debt. Sometimes they work out of a cramped or less ergonomic office, you could call that facilities debt.Sometimes startup founders have very little management experience and hire others who have very little experience, you could call that management debt.Taking on debt of any kind should be done strategically with a clear awareness of the trade-offs associated with it.There's nothing intrinsically bad about any of the types of debt.I think the most useful mental model is more risk-oriented. Think of the business as a portfolio of risks. Adopting a zero technical debt strategy reduces the risk of unexpected technology failures, but increases the risk of competitors coming to market sooner, etc. Successful businesses are the ones that navigate and make choices that turn out in hindsight to have been smart about the allocation of that risk portfolio.In my view the relevant case study for technical debt is that day years ago when Facebook's homepage malfunctioned and showed the PHP source. This revealed some pretty ugly code that had apparently been written by Zuckerberg. Facebook already had a valuation in the billions on the basis of code that would not pass code review at most startups.

viseztrance将近 4 年前

> Debt repayment has one vital characteristic: it is easy to understandIf it were this easy you wouldn't see so many people taking on so many unnecessary debts. Technical or otherwise.

评论 #28005794 未加载

keithnz将近 4 年前

this article takes the metaphor way too seriously. At best, this is language we can use to help clarify what things we need to focus on and the trade off, most often useful when describing things to non technical people. At worse, it can be taken in such a way that we try to quantify the debt so it can be seen how badly things are screwed up. Its not a metric and doesn't really have a strong definition, it's more conceptual.

Andy_G11将近 4 年前

The need to maintain or replace / upgrade infrastructure places an obligation (liability) on the owner of the infrastructure to do so.Perhaps technical liability would be more accurate, but I like the sound of technical debt.There is always the temptation to say, 'We have made something. It works. Pure asset.' (E.g. concept of passive income.) But it is seldom true over the long term. The debt is almost always there, or will be as the rest of the world moves on and the existing asset needs to be developed or becomes obsolescent.The trick for asset owners (asset defined as the right to future economic benefits) to profit from an asset is to spend some of the returns from the asset on paying others to maintain and refresh the asset. In this way, the asset owner enjoys the truly passive net benefit.Infrastructure carries both the attributes of a static, tangible thing (a good) and a service.I like that the coding world is so conscious of technical debt, and it makes sense: the sector is moving so fast, and the fixes can be applied with access to a skilled problem solver, a computer, access to software and time. The maintenance &/or switching costs are comparatively low in comparison to the benefits.I think that providers of physical infrastructure could pay more attention. Maintenance contracts and dilapidation reserves do make (small) inroads into acknowledging the ultimate sclerosis that additional large infrastructure introduces to the built environment. But the time scales for its regeneration to a large extent alleviate developers from the obligation to apply a more overarching perspective of the debt it will place on future generations to improve on what has been laid down.Rather than questioning the term, it should be rolled out more widely.

ziggus将近 4 年前

Just because this guy doesn't clearly understand technical debt doesn't mean that his experience is universal. This sounds like something an MBA would write.If you're an experienced (or even somewhat inexperienced) developer working on projects of even minor complexity or in a domain you don't quite understand, you know exactly what technical debt is, and probably have plenty of it.

ape4将近 4 年前

Wikipedia has a reasonable definition: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]<a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow">https://en.wikipedia.org/wiki/Technical_debt</a>

评论 #28007445 未加载

zug_zug将近 4 年前

Sounds like there is rightly a lot of mistrust of technical debt (rightly because about half of the things one engineer calls technical debt "Rewrite that service in go" another engineer calls perfectly fine).Perhaps it's best for everybody involved if we define "hard technical debt," which meets the highest criteria.1. The interest is in measurable engineer-time (not risk, not user-experience, not sales, not satisfaction). E.G. "Every time we deploy it takes the scripts 30 minutes to run, and I can't switch focus for those 30 minutes"2. The capital is in measurable time. "It would take 15 work hours to fix that script, with planning, debugging, documentation, etc"With those two, we can calculate the annual interest rate at 173% (at 1 deploy per week).This would help separate people who love doing rewrites because it's fun to put their name on things from actual "this is wasting my time every day" concerns.

morgelgluff将近 4 年前

My pet issue with technical debt, is what happens when engineers are allowed to pay it down.In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time.Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equally problematic.In the worst case, you have a combination of ignorance and best-practice-hysteria that gets applied to actually-fit-for-purpose code. Then the 200 lines of performant and correct code that takes two hours to fully understand, gets turned into 2000 lines of deeply nested class hierarchies mixed with immutable FP-wank that takes several days to get a grasp of and both fails to handle real-world data (“not in the specification!”) and tanks system performance (“premature optimizations!”).

评论 #28006122 未加载

评论 #28007619 未加载

DoreenMichele将近 4 年前

I happened to write a comment giving my understanding of technical debt 27 days ago:<a href="https://news.ycombinator.com/item?id=27720078" rel="nofollow">https://news.ycombinator.com/item?id=27720078</a>FTA:Debt repayment has one vital characteristic: it is easy to understand. Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term (i.e., length of time to repay).I think the author is making an argument that it isn't really debt based on a failure to understand debt.Actual debt isn't really somehow magically simpler and more straight forward than technical debt. It's kind of a bet that taking this hit now will pay off enough that it will be worth it.It's a context based decision that compares a hypothetical path over time and guesses what will get the greatest overall benefit.There is a saying in the military: Sometimes, a 90 percent solution now is better than a 100 percent solution later.Life is a series of bets always based on partial information where we try to navigate our way through this one-way time travel adventure where we all move inexorably into the future minute by minute without knowing exactly what will happen. Choose poorly and things can really go to hell. Choose wisely and you can see life get better.There's always some luck or randomness involved. Whether it's a good decision or a bad one will depend in part on if the future takes the direction you think it will.Actual financial debt is no less complicated than technical debt. Someone who is more programming literate than I am could probably come up with some equivalent mental model for how technical debt gets repaid: "There are three components to repaying technical debt..."The real issue in both cases is the question "Is it good debt or bad?" In other words, (for technical debt) did this decision to do something quick and dirty provide more value than it will cost to clean up later?For money, it's theoretically easy to put numbers to the road not taken. In practice, it's a lot harder.It's relatively easy when it's a hypothetical model. Real life has other factors that get hard to fully account for, especially if you have to justify it to someone else whose views of what is pertinent may differ dramatically from yours.

imbnwa将近 4 年前

I know we loathe these kinds of comments but that site was hard to read with that thin font and crazy low contrast

评论 #28007615 未加载

bryanrasmussen将近 4 年前

things for which analogies are made are not actually 100% the same as the thing the analogy says they are like, that's actually sort of the point.and I say that as someone who doesn't much like analogies or metaphors for most code management issues as I think they often obfuscate the problems more than they illuminate.

stared将近 4 年前

Why do we ever need to do write tests if the code works?Why do we create encapsulated build setups if everyone from the team knows how it install it on their machines anyway?Why do we waste time on writing documentation?And above all: if during a three-day hackathon we can create a game, why does it take months or years to create a publishable one?

评论 #28007783 未加载

strogonoff将近 4 年前

My take on technical debt is that it’s a mismatch between requirements then and requirements now. And I don’t mean the written spec, I mean the dauntingly complete extent of requirements that exists mostly unverbalized in architect’s mind and applies to software’s existence in respective subject domain landscape over time (relating to maintenance effort, evolution of software, evolution of subject landscape, and so on).I think the term “technical debt” is useful in the sense that it can do a good job of conveying the gist of the consequences of this mismatch that matter to people outside the development, without the above esoterics which I’d do a poor job at communicating (without confusing or alarming my target audience, anyway).

city41将近 4 年前

I didn't really agree with anything in this article and to be honest it feels like the whole thing was written just to be contrarian.Its definition of "debt" is too strict. Sure if you take on a mortage or a bank loan, then principle, interest and term will be well defined and enforced. What about when you borrow twenty bucks from your friend or they help you move?Arguing that technical debt is not technical because it has a broader impact doesn't really seem very important. Calling it "technical" because it originates in a technical part of the company and while building out tech makes perfect sense to me. The fact it can have a broader impact doesn't seem very important when naming it.

razeonex将近 4 年前

I'm not particularly fan of one person coining a term and have everybody agree on that, I think every team should create its own glossary of terms and always compare against different authors that may have gone deeper analyzing a given topic. There are some terminology that makes sense for some contexts and other that simply not. It may make sense for me to call something in a certain way because my team understands and we all have agree on what are we referring to, instead of having someone to tell us how to call things.I really like this kind of epistemological analysis on tech terms, specially those that we use all the time and that we think we understand, but mainly for going deeper on a topic and analyze.

评论 #27994468 未加载

评论 #28005718 未加载

mikewarot将近 4 年前

So it's really not technical debt, but rather cognitive debt? In Rumsfeldian, it is the difference between the current known knowns and the previous known unknowns. That hard won knowledge should be plowed into the source code, via refactoring, before it is lost.Source code is the expression of knowledge about a problem that happens to be machine readable.Test code is the expression of knowledge about how things can go wrong solving the problem, and it happens to be machine readable as well.I agree that a sad aspect to this is the use of a money metaphor. Once the Silicon Valley types hear a finance term, they lock on to it as something to be optimized, and deployed as a tool. It leads people astray.

ggm将近 4 年前

As a believer in tech debt the centrepiece of my disagreements with non believers does go to the nature of debt and interest: they don't believe you accrue any extra burden delaying work to the end. I do: the accumulation of technical delay, imposes additional costs which would not have existed had you amortised the update across time. Complexity, tooling, shifts in underlying dependencies all become worse the more generations against "current" you have to transit.It rarely costs less to delay tech work. It often costs more. The "moral force" of the debt analogy is strong.

评论 #28006213 未加载

smitty1e将近 4 年前

If the phrase "technical debt" seems a misnomer, consider: "pay me now or pay me later".TD is any code/architecture aspect to which PMNOPML applies.As with gravity, it's going to suck whether one fancies the label or not.

xaduha将近 4 年前

It's not a good term, but the meaning is clear enough. You can't keep sweeping things under a rug indefinitely, your ass is due for some biting because of accumulation of poor decisions.

victor9000将近 4 年前

Ok, so the article basically said to comment before reading. So technical debt is anything in your codebase or infrastructure that makes things harder in the development process or limits the set of features that you can offer. You live with it because this limitation is not completely blocking, otherwise you would actually fix it, but you also don't want to forget about it or pretend like it doesn't exist. So you track it and call it technical debt, it's effectively an IOU to your future self.

评论 #28006242 未加载

rwoerz将近 4 年前

"... an amorphous ghost, with enormous differences and inconsistencies in its use.""Technical debt" is good company here. Popular speakers, thought leaders and the like are rather keen to coin new terms but not to define and delineate them rigorously.(Like for "microservices": Let two engineers count the number of microservices in a larger system. The will surely not arrive at the same number.)

anm89将近 4 年前

As someone who makes a pretty good living cleaning up technical debt messes, I'd beg to differ.It's remarkable how much substance there is to the technical debt metaphor.1) There is good debt and bad debt. It's only good debt if it buys you an asset that creates a value stream.2) There is compounding interest over time on technical debt.3) You can metaphorically go bankrupt from technical debt. (IE total project failure and or abandonment)

paphillips将近 4 年前

'Technical Debt' in contemporary terms has certainly become a container holding far more than originally intended by Cunningham.The fundamental debt metaphor was about the need for ongoing re-factoring of past code and systems to match today's understanding, and the accumulating cost of failing to have the discipline and taking the time to do so.Cunningham's specific quotes from the video [0] linked in the article: "...accumulate the learnings we did about the application over time by modifying the program to look as though we knew what we were doing all along, and to look as if it had been easy to do", and "If we fail to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement, and that would slow us down".This problem is fundamental to software systems and how they change over time, and is not about making poor choices, tradeoffs, or generally poor engineering to ship code faster.A system or feature is initially built based on the requirements that were known at that point in time. Requirements are frequently not static though: that original set of requirements may continue to evolve over time, either as we better understand them after implementation, or when requirements are added, refined, or removed by the stakeholders or organization.Additionally, we can't view each feature or requirement in isolation over time: only when we see the overall set of features in a system will the important patterns start to emerge that inform how refactoring should occur. We can't know this early on, only over time as the system evolves.I have witnessed this many times on software projects, both small and large. Requirements and features evolve over time, but the code base was never refactored to take into account the overall understanding as of each point in time. Rather, the changes are applied in isolation ('bolted on?') incrementally. Over time these numerous incremental changes result in a system that is fragile, increasingly difficult to understand and maintain, and generally veers toward spaghetti. It becomes harder and harder to make changes. That is the debt that was never repaid.[0] <a href="http://www.youtube.com/watch?v=pqeJFYwnkjE" rel="nofollow">http://www.youtube.com/watch?v=pqeJFYwnkjE</a>

renewiltord将近 4 年前

Surely this discussion will ultimately merely degenerate into prescriptivists vs descriptivists?For my part, I use the term sparingly since I find I can easily use it as a catch-all thought-terminating cliche. That doesn’t mean it is useless. Just that it’s bad for me to use it.People around me know to not let me get away with saying that.

wilde将近 4 年前

> Debt repayment has one vital characteristic: it is easy to understand.What? The US consumer debt industry would beg to differ.I was hoping that maybe they’d extend the concept to a liability or something. In general the idea is that you’re borrowing a resource from your future self to accelerate a business outcome now.

KingOfCoders将近 4 年前

I tell all my coachees not to use "technical debt" outside of technology, if ever. Same goes for the phrase "refactoring", don't use it outside technology.

评论 #28005487 未加载

skeeter2020将近 4 年前

Slightly OT: please don't style your blog to be various shades of faint grey. I'd love to read about your ideas but I just can't so, movin' on...

Pokepokalypse将近 4 年前

Technical debt is what happens when an accountant is doing an engineer's job.

omgitsabird将近 4 年前

I didn't know Ward Cunningham had a YouTube channel.

majkinetor将近 4 年前

TLDR> Cunningham: I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.Technical debt is not about technology, but about better understanding of functional domain, after which you should refactor your current implementation to better reflect reality in the sense that there is a more clean abstraction and accompanied code.

评论 #28006233 未加载

billylindeman将近 4 年前

I like to say a full rewrite is technical bankruptcy