13 Matching Annotations
  1. 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
  2. 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.
  3. 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.

  4. 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.
  5. Feb 2020
  6. 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.
  7. 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