3 ms·

> If the technical debt is a problem, 1) we shouldn’t have put it in there I guess it depends on your definition of tech debt, but there are lots of examples o

by afro88 2y ago

> If the technical debt is a problem, 1) we shouldn’t have put it in there I guess it depends on your definition of tech debt, but there are lots of examples of things that aren't tech debt at the time but become tech debt over time. You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency you needed to upgrade, and you need a few days to figure it out. A cabinet maker might not put "make tenons straight" in a sprint, they would include it in the estimate and not tell the customer, sure. But they would definitely tell the customer that their lathe tool broke and they needed a few days for repair before continuing work.

skydhash 2y ago
> You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency This is a solved problem. You either understand the dependency enough to maintain it yourself, or you firewall it through interfaces. Or you tie yourself to sensible projects that gives you time for upgrade. Or you pay for support. Every decision should be taken with a complete understanding of pros and cons, and risk management to reduce the latter. This cabinet make should either have a backup tool or be confident they can do the repair in a way that doesn't impact their consumer.
- afro88 2y ago
  You do need to understand the pros and cons, and wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces. I wasn't talking about blindly doing stuff without understanding consequences and risk managing. I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today. Firewalling all interfaces to dependencies for example can be future tech debt if you need to move fast to stay ahead of competitors, but all the indirection is making development too slow (or causing developers to find other more enjoyable work). Can't imagine working on a React codebase where React is completely abstracted behind our own interfaces to all of it.
  - skydhash 2y ago
    > I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today. I agree > wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces. I'm not saying you should firewall everything. But if it make sense, you do so. You also need someones that understand each core deps enough they can patch it if the maintainers won't resolve an issue (happens more in the npm world). Even with React, you can extract the business logic and reuse it elsewhere. The goal is to avoid depending that much on projects that have less stability than yours (some bad experiences here with React Native). How you do it is contextual, but you should keep it in mind.
    - afro88 2y ago
      Ah I see now, you took issue with the example specifically, rather than the point. You're right, I see how it's a bad example, and what you've laid out is a very good way of handling dependencies.

by afro88 2y ago

skydhash 2y ago

> You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency This is a solved problem. You either understand the dependency enough to maintain it yourself, or you firewall it through interfaces. Or you tie yourself to sensible projects that gives you time for upgrade. Or you pay for support. Every decision should be taken with a complete understanding of pros and cons, and risk management to reduce the latter. This cabinet make should either have a backup tool or be confident they can do the repair in a way that doesn't impact their consumer.

afro88 2y ago
You do need to understand the pros and cons, and wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces. I wasn't talking about blindly doing stuff without understanding consequences and risk managing. I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today. Firewalling all interfaces to dependencies for example can be future tech debt if you need to move fast to stay ahead of competitors, but all the indirection is making development too slow (or causing developers to find other more enjoyable work). Can't imagine working on a React codebase where React is completely abstracted behind our own interfaces to all of it.
- skydhash 2y ago
  > I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today. I agree > wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces. I'm not saying you should firewall everything. But if it make sense, you do so. You also need someones that understand each core deps enough they can patch it if the maintainers won't resolve an issue (happens more in the npm world). Even with React, you can extract the business logic and reuse it elsewhere. The goal is to avoid depending that much on projects that have less stability than yours (some bad experiences here with React Native). How you do it is contextual, but you should keep it in mind.
  - afro88 2y ago
    Ah I see now, you took issue with the example specifically, rather than the point. You're right, I see how it's a bad example, and what you've laid out is a very good way of handling dependencies.