And or add more of it. This is why I don't like the analogy of technical debt and "paying it down". Half the time that's just adding more spaghetti that works around your "technical debt" and adds more. I prefer the metal work hardening analogy. As you add more layers and complexity to your system, it becomes harder to work. When you then try to remold it to "make it more flexible," you are again making decisions and locking in choices, so you are making it less flexible in other dimensions.
Technical debt is this idea that as something ages it becomes harder to modify because of poor initial choices. These choices are a debt that make you pay interest on any new thing you want to do. But these payments and even these fixes just make it harder.
Example. Microsoft has to work with code from multiple eras including DOS code, NT era, ME era, Vista era, 7, 10. 11 was a big overhaul. But in 20 years it will just represent another era of changing strategies rolled up into one code ball that will feel just as odd as anything that was done in the DOS era. So they didn't pay down debt. The further hardened the piece by working it.
This is why I can be hesitant or at least not instant to add a feature that only one user is requesting. I might be worth the work. But is it worth making every next feature harder.
In the meantime, Green says, update your software. “If your phone is like, ‘Hey, there’s a security update available, do you want to install it,’ don’t wait till next week. Just do it.”
And that's how they'll snare a lot of first-adopter folks with malware embedded in a future update.
It's happened before.
Rule of thumb:
Definitely don't be last, and don't be the first adopter of new tech.
The real questions are: when is the ideal window, and how long is the grace time?
Log in
And or add more of it. This is why I don't like the analogy of technical debt and "paying it down". Half the time that's just adding more spaghetti that works around your "technical debt" and adds more. I prefer the metal work hardening analogy. As you add more layers and complexity to your system, it becomes harder to work. When you then try to remold it to "make it more flexible," you are again making decisions and locking in choices, so you are making it less flexible in other dimensions.
Technical debt is this idea that as something ages it becomes harder to modify because of poor initial choices. These choices are a debt that make you pay interest on any new thing you want to do. But these payments and even these fixes just make it harder.
Example. Microsoft has to work with code from multiple eras including DOS code, NT era, ME era, Vista era, 7, 10. 11 was a big overhaul. But in 20 years it will just represent another era of changing strategies rolled up into one code ball that will feel just as odd as anything that was done in the DOS era. So they didn't pay down debt. The further hardened the piece by working it.
This is why I can be hesitant or at least not instant to add a feature that only one user is requesting. I might be worth the work. But is it worth making every next feature harder.
Cyber psyop fear porn?
And that's how they'll snare a lot of first-adopter folks with malware embedded in a future update.
It's happened before.
Rule of thumb:
The real questions are: when is the ideal window, and how long is the grace time?
Rothschild spends a lot on propaganda to make us think debt can't easily be disregarded and not paid back.