4 ms·

The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time

The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.

zuppy 6y ago
> is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc
- magicalhippo 6y ago
  There can be many very valid reasons for creating technical dept when writing code. That does not mean technical dept is not a thing or not a real issue in certain codebases. Almost every day I think about the potential technical dept of my code.
- gwd 6y ago
  Sure, and that's actually 100% normal in business -- it's called the "J-curve". Lots of businesses big and small start their lives, or even start some new project or expansion within an existing business, by borrowing money and then paying it back. The key thing is 1) borrowing money "strategically", and not just willy-nilly and 2) paying it back when you can afford to, rather than continually paying interest on it. It totally makes sense to take on technical debt in order to get your MVP out the door quickly; or to be able to fix an urgent customer issue; or to be able to make a release. And in some cases, it may make sense to keep technical debt around indefinitely. What doesn't make sense is to pile on technical debt for no real benefit, and then not take any time to pay it down. That's like always buying things on your credit card just because you can and only making the minimum payments.
rumanator 6y ago
> “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This is the wrong way to describe and explain technical debt. It fails primarily to sell the wrong idea that technical debt results from incompetence or failure to do a good job. The truth if the matter is that in software development the absolute best solution to a problem is to provide an implementation that meets current requirements and is implemented as fast as possible. Overgeneralizing is bad code. Abstracting implementation details is a code smell. Proposing an implementation that considers additional design requirements and constraints is goldplating a solution, thus the sign of a mix of incompetence and wasted effort. But then what if requirements change? Ah, the delta between the fast and good solution for the initial problem and adapting it with quick fixes to address the new requirements is precisely where technical debt pops up.
- adrianmonk 6y ago
  You made a good argument that generalizing is an investment that often doesn't pay off. That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
  - rumanator 6y ago
    > That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
- xixixao 6y ago

zuppy 6y ago

> is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc

magicalhippo 6y ago
There can be many very valid reasons for creating technical dept when writing code. That does not mean technical dept is not a thing or not a real issue in certain codebases. Almost every day I think about the potential technical dept of my code.
gwd 6y ago
Sure, and that's actually 100% normal in business -- it's called the "J-curve". Lots of businesses big and small start their lives, or even start some new project or expansion within an existing business, by borrowing money and then paying it back. The key thing is 1) borrowing money "strategically", and not just willy-nilly and 2) paying it back when you can afford to, rather than continually paying interest on it. It totally makes sense to take on technical debt in order to get your MVP out the door quickly; or to be able to fix an urgent customer issue; or to be able to make a release. And in some cases, it may make sense to keep technical debt around indefinitely. What doesn't make sense is to pile on technical debt for no real benefit, and then not take any time to pay it down. That's like always buying things on your credit card just because you can and only making the minimum payments.

rumanator 6y ago

> “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This is the wrong way to describe and explain technical debt. It fails primarily to sell the wrong idea that technical debt results from incompetence or failure to do a good job. The truth if the matter is that in software development the absolute best solution to a problem is to provide an implementation that meets current requirements and is implemented as fast as possible. Overgeneralizing is bad code. Abstracting implementation details is a code smell. Proposing an implementation that considers additional design requirements and constraints is goldplating a solution, thus the sign of a mix of incompetence and wasted effort. But then what if requirements change? Ah, the delta between the fast and good solution for the initial problem and adapting it with quick fixes to address the new requirements is precisely where technical debt pops up.

adrianmonk 6y ago
You made a good argument that generalizing is an investment that often doesn't pay off. That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
- rumanator 6y ago
  > That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
xixixao 6y ago