3 ms·

I would say technical debt is only that which you already know about but have made an intentional decision to take out a “loan” to ship quickly. I’m having tro

I would say technical debt is only that which you already know about but have made an intentional decision to take out a “loan” to ship quickly. I’m having trouble thinking of an example of financial debt that can be taken on unknowingly. Maybe identity theft? But that's less like an engineering tradeoff... more like NSA backdoor type stuff.

crimsonalucard 7y ago
Debt heavy choices made knowingly are more rare, as programmers consciously avoid it or choose debt that won't accumulate beyond certain bounds. Whatever it is, I think most projects deal with "technical debt" accumulated unknowingly. There's no theory around how to create a "good design" and thus it's often shooting in the dark or using preexisting patterns. Most software projects have design flaws that only become evident later. In my career, I have dealt with this type of problem more-so then debt accumulated knowingly. Additionally my current company is calling this type of debt, technical debt. I have rarely rarely seen technical debt taken on knowingly and documented.
- helen___keller 7y ago
  > Debt heavy choices made knowingly are more rare, as programmers consciously avoid it or choose debt that won't accumulate beyond certain bounds I don't know what kind of software you work on, but I disagree. It's incredibly common, from what I've worked on, that we have an existing subsystem X, and project management wants it to interact with this new subsystem Y but it was never designed in a way to do so, so either we can hack it in real quick, build a moderately pleasing integration with only a little technical debt, or completely rebuild X from the ground up in a way that makes sense and leaves no technical debt. From my experience, bad managers will want the quick hack while engineers and good managers will take the middle option. Nobody opts for the complete rebuild.
  - crimsonalucard 7y ago
    The design of subsystem Y is likely technical debt. The reason is, because of agile, software developers know that they must code defensively to account for feature changes or additions in the future. That means you take on technical debt every time you make a subsystem that isn't modular, meaning that if system Y is not infrastructure it should be able to be pulled out and used somewhere else. To not account for this feature is to not account for future change. A good way to test if your subsystem is modular is to ask yourself, can you pull your subsystem out of the current system and use it in a completely different app in a completely different context? If the answer is no, then likely the module is either IO or too tightly coupled with other systems. Too much Mocking in your tests is another sign of a design flaw. It's a signal that your code is dependent on other systems rather than a module that can be pulled out and reinserted somewhere else. Another design flaw is, is system Y itself made up of modules or interconnected dependencies? If subsystem Y needs to reconfigured to do something slightly different can I pull out 10% of the system and replace it with new modules? Or does pulling out 10% of the system involve pulling out another 80% of the system as a dependency? You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. Most programmers choose dependencies because modules are harder. Also the dependency style of programming is heavily promoted. Additionally, most programmers are Unaware of what it means to make a modular component, they organize code following nomenclature rather than a systematic theory, and they think they are doing modular design but they are not. Likely your subsystem Y was designed in such a way that it is tightly coupled to another subsystem and can't be used outside of a certain context. Possibly it is tightly coupled with IO or some specific database schema. Likely system Y itself is made up of modules that are interdependent. Also likely it was programmed by someone who did all of this unknowingly. So it could be a matter of perspective. What you see as debt taken on deliberately I see as debt from the past "discovered" and interest accrued because the debt can't be paid back without a rebuild.

crimsonalucard 7y ago

Debt heavy choices made knowingly are more rare, as programmers consciously avoid it or choose debt that won't accumulate beyond certain bounds. Whatever it is, I think most projects deal with "technical debt" accumulated unknowingly. There's no theory around how to create a "good design" and thus it's often shooting in the dark or using preexisting patterns. Most software projects have design flaws that only become evident later. In my career, I have dealt with this type of problem more-so then debt accumulated knowingly. Additionally my current company is calling this type of debt, technical debt. I have rarely rarely seen technical debt taken on knowingly and documented.

helen___keller 7y ago
> Debt heavy choices made knowingly are more rare, as programmers consciously avoid it or choose debt that won't accumulate beyond certain bounds I don't know what kind of software you work on, but I disagree. It's incredibly common, from what I've worked on, that we have an existing subsystem X, and project management wants it to interact with this new subsystem Y but it was never designed in a way to do so, so either we can hack it in real quick, build a moderately pleasing integration with only a little technical debt, or completely rebuild X from the ground up in a way that makes sense and leaves no technical debt. From my experience, bad managers will want the quick hack while engineers and good managers will take the middle option. Nobody opts for the complete rebuild.
- crimsonalucard 7y ago
  The design of subsystem Y is likely technical debt. The reason is, because of agile, software developers know that they must code defensively to account for feature changes or additions in the future. That means you take on technical debt every time you make a subsystem that isn't modular, meaning that if system Y is not infrastructure it should be able to be pulled out and used somewhere else. To not account for this feature is to not account for future change. A good way to test if your subsystem is modular is to ask yourself, can you pull your subsystem out of the current system and use it in a completely different app in a completely different context? If the answer is no, then likely the module is either IO or too tightly coupled with other systems. Too much Mocking in your tests is another sign of a design flaw. It's a signal that your code is dependent on other systems rather than a module that can be pulled out and reinserted somewhere else. Another design flaw is, is system Y itself made up of modules or interconnected dependencies? If subsystem Y needs to reconfigured to do something slightly different can I pull out 10% of the system and replace it with new modules? Or does pulling out 10% of the system involve pulling out another 80% of the system as a dependency? You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. Most programmers choose dependencies because modules are harder. Also the dependency style of programming is heavily promoted. Additionally, most programmers are Unaware of what it means to make a modular component, they organize code following nomenclature rather than a systematic theory, and they think they are doing modular design but they are not. Likely your subsystem Y was designed in such a way that it is tightly coupled to another subsystem and can't be used outside of a certain context. Possibly it is tightly coupled with IO or some specific database schema. Likely system Y itself is made up of modules that are interdependent. Also likely it was programmed by someone who did all of this unknowingly. So it could be a matter of perspective. What you see as debt taken on deliberately I see as debt from the past "discovered" and interest accrued because the debt can't be paid back without a rebuild.