121–130 of 147 posts
Earlier quoted context omitted.
"Technical debt is the burden that implementation choices may place on future development." Any choice you make now, may place a burden in some possible future.
Some more than others.
"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.)
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.
https://news.ycombinator.com/item?id=27720078
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.
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.
Earlier quoted context omitted.
> "Technical debt is the burden that implementation choices may place on future development." > With regard to its coherence, I say that it is empirically verified: it actually happens! Something happens, on this we can agree, but if you are making checkers and find out you need chess, it isn't that making chess is any harder than it was before you did anything -- so no, I would not agree that it placed any burden on…
not all "technical debt" is wanting chess when we built checkers. it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess. the vast majority of software projects will have features/requirements that evolve after the initial design, it is a rabbit hole to try and guess all of those, but some things are just common sense but would a…
You should not build something you do not need if you know it is wrong and you will not need it.
That is just wrong.
Many engineering managers do this to “show progress” but this is because they are bad at their job.
On the other hand, if you need it so the UI team has a mock to work against (so that they can explore what interfaces they really need), it isn’t debt at all.
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 irr…
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 h…