16 Matching Annotations
  1. Nov 2022
    1. The paradox of information systems[edit] Drummond suggests in her paper in 2008 that computer-based information systems can undermine or even destroy the organisation that they were meant to support, and it is precisely what makes them useful that makes them destructive – a phenomenon encapsulated by the Icarus Paradox.[9] For examples, a defence communication system is designed to improve efficiency by eliminating the need for meetings between military commanders who can now simply use the system to brief one another or answer to a higher authority. However, this new system becomes destructive precisely because the commanders no longer need to meet face-to-face, which consequently weakened mutual trust, thus undermining the organisation.[10] Ultimately, computer-based systems are reliable and efficient only to a point. For more complex tasks, it is recommended for organisations to focus on developing their workforce. A reason for the paradox is that rationality assumes that more is better, but intensification may be counter-productive.[11]

      From Wikipedia page on Icarus Paradox. Example of architectural design/technical debt leading to an "interest rate" that eventually collapsed the organization. How can one "pay down the principle" and not just the "compound interest"? What does that look like for this scenario? More invest in workforce retraining?

      Humans are complex, adaptive systems. Machines have a long history of being complicated, efficient (but not robust) systems. Is there a way to bridge this gap? What does an antifragile system of machines look like? Supervised learning? How do we ensure we don't fall prey to the oracle problem?

      Baskerville, R.L.; Land, F. (2004). "Socially Self-destructing Systems". The Social Study of Information and Communication Technology: Innovation, actors, contexts. Oxford: Oxford University Press. pp. 263–285

  2. Mar 2021
  3. Nov 2020
    1. this is treated as debt work for of us and that's usually tackled during the first week in the milestone (roughly the first week in the month)
  4. Oct 2020
    1. And if they are a technical debt - how do measure up how much you can borrow so you can afford the repayments?
    2. debt ... which is not a straight bad thing but something that could provide some "short term financing" get us to survive the project (how many of us could afford to buy a house without taking out the mortgage?).
    3. But recently I started to think about default values as some sort of a technical debt ... which is not a straight bad thing but something that could provide some "short term financing" get us to survive the project
  5. Sep 2020
    1. Customers care more about the value our application adds to their lives than the programming language or framework the application is built with. Visible Technical Debt such as bugs and missing features and poor performance takes precedence over Hidden Technical Debt such as poor test code coverage, modularity or removing dead code
    2. In the real world — the time to pay off technical debt is scarce — in most of the time fueled by the fear of the unknown. The management loves to milk the cow but not to change the litter. The developers on another hand avoid modernizing legacy code — to avoid trouble in case anything breaks.
    3. You are in crossroad to make a big decision: keep increasing the tech debt or start the migration before it is too late.
  6. May 2020
    1. AppCache was standardized in the Offline Web applications section of the HTML specification. The standard is formally referred to as application caches. New Web applications should be built around Service Workers. Existing applications that use AppCache should migrate to Service Workers. AppCache access was removed from insecure origins in M70. This intent addresses AppCache usage in secure origins.

      First and foremost, AppCache is a deprecated standard with serious architectural concerns. Second, Chrome's AppCache implementation is a security and stability liability. AppCache is documented as deprecated and under removal in MDN and in the WHATWG standard, and marked as obsolete in W3C’s HTML 5.1. It is incompatible with CORS, making it unfriendly for usage with CDNs. Overall, AppCache was changed in over 400 Chromium CLs in 2018-2019. It has imposed a tax on all of Chrome’s significant architectural efforts: Mojofication, Onion Souping, and the Network Service. The security benefits of the removal are covered under Security Risks.

    1. after nearly 10 years of continuous improvement

      Not necessarily a good or favorable thing. It might actually be preferable to pick a younger software product that doesn't have the baggage of previous architectural decisions to slow them down. Newer projects can benefit from both (1) the mistakes of previously-originated projects and (2) the knowledge of what technologies/paradigms are popular today; they may therefore be more agile and better able to create something that fits with the current state of the art, as opposite to the state of the art from 10 years ago (which, as we all know, was much different: before the popularity of GraphQL, React, headless CMS, for example).

      Older projects may have more technical debt and have more legacy technologies/paradigms/integrations/decisions that they now have the burden of supporting.

  7. Apr 2020
    1. The result, all too often, is that we decide (often unconsciously) that the sweeping change just isn't worth it, and leave the undesirable pattern untouched for future versions of ourselves and others to grumble about, while the pattern grows more and more endemic to the code base.
  8. Feb 2020
  9. Jul 2015
    1. TECHNICAL DEBT: A lot of new code is written very very fast, because that’s what the intersection of the current wave of software development (and the angel investor / venture capital model of funding) in Silicon Valley compels people to do. Funders want companies to scale up, quickly, and become monopolies in their space, if they can, through network effects — a system in which the more people use a platform, the more valuable it is. Software engineers do what they can, as fast as they can. Essentially, there is a lot of equivalent of “duct-tape” in the code, holding things together. If done right, that code will eventually be fixed, commented (explanations written up so the next programmer knows what the heck is up) and ported to systems built for the right scale — before there is a crisis. How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there’s the temptation for more duct tape. And so on.
  10. Jun 2015
    1. Instead of thinking of technical debt as yesterday’s work that I failed to do, I think of it as tomorrow’s feature I can have today