71–80 of 198 posts
The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.
I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.
Maintenance also has a second aspect: Bitrot. 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't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem. The thing is, I have never met a manager that budgeted this fromt he get go. But I also never me…
Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former.
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.
Earlier quoted context omitted.
Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."
Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off" of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"
Earlier quoted context omitted.
Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.
I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull requ…
It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand .
Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly."
Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.
Earlier quoted context omitted.
Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off" of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"
Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.
Earlier quoted context omitted.
I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.
Earlier quoted context omitted.
It is essentially the same as financial debt, too much debt and you go bankrupt, but if you refuse to take some debt, you may lose opportunities. The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don'…
It is not the same. Financial debt has to be on the balance sheet; technical debt is not. My point is the a finance/business guy will think in the totally wrong direction with what you actually mean. Also to whom do you repay technical debt?
Earlier quoted context omitted.
And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility. They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say,…