Dealing with Technical Debt

  • David.Poole - Saturday, March 16, 2019 4:25 AM

    For me technical debt is putting in place something that will be a pain point that will manifest from early on and which is known to be a pain point at the time it goes into production.
    The stateful nature of data magnifies that pain.
    The point of technical debt is to provide a competitive advantage to the organisation. If you don't address technical debt then that advantage will be lost when the interest payments (in the form of additional mitigation actions) start to bite.
    The important thing is to gain a shared understanding of the benefits and cost and an honest agreement as to the repayment plan terms.

    That's mostly what I'm talking about.

    I think the "competitive edge" by allowing "technical debt" becomes a disaster because no one goes back to fix the junk they're built to get things out quickly because they're too damned busy trying to be "competitive". 😉  Then when stuff fails due to scalability issues (which usually happens when your customers can least afford it to happen), the company's reputation gets a proverbial "black eye" and bad news travels really fast not only possibly causing the loss of the current customer but possibility also preventing the acquisition of future customers.

    To quote you from above...

    For me technical debt is putting in place something that will be a pain point that will manifest from early on and which is known to be a pain point at the time it goes into production.


    I totally agree and that's mostly what I'm talking about.  To add to that, people say they don't have people that have the necessary skills to recognize those things.  All I can say is "Are you sh**ing me"?  What a lame excuse.  Are they in business or not?  A company that manufactures vehicles has the right people to do the job.  Why do so many consider software to be different?

    Serious case in point... the two 737 MAX planes that crashed didn't crash because of hardware failures.  They crashed because of software failures.

    I know what folks will say about that... "We're not writing software where people's lives are at stake".  To that, I say rubbish.  If the company does poorly and there are layoffs, that can actually cause death.  I know because a large company I used to work for had layoffs even though I told them 2 years ahead of time that they had a problem and, on the month and year I predicted, they had to layoff about half of the people (roughly 1500 people).  3 people died because they could no longer afford their treatments for illnesses.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • David.Poole - Saturday, March 16, 2019 4:25 AM

    For me technical debt is putting in place something that will be a pain point that will manifest from early on and which is known to be a pain point at the time it goes into production.
    The stateful nature of data magnifies that pain.
    The point of technical debt is to provide a competitive advantage to the organisation. If you don't address technical debt then that advantage will be lost when the interest payments (in the form of additional mitigation actions) start to bite.
    The important thing is to gain a shared understanding of the benefits and cost and an honest agreement as to the repayment plan terms.

    For the most part, I agree with you, but not entirely. I think I mentioned, early in this thread for this topic, that we're dealing with a lot of technical debt at work. However, reading your post here I now realize that it is very likely the men and women who've left us with so much technical debt didn't really leave us with the technical debt at the time they wrote the things they wrote. 10 to 15 to maybe as many as 20 years ago, when they wrote the MS Access apps or the Excel spreadsheets upon which so many sections throughout our enterprise now depend, were not, when they were wrote, technical debt. Those poor folks were only doing what they could with what they had at hand and the knowledge and skillsets they were working with. I've really been unfair to those original developers. I have an issue with the lack of effort to upgrade those Access apps or convert to an app those Excel spreadsheets, as time and technologies have moved on. In particular the really old Access apps we have. Many are beginning to fail now, because Windows updates have, over the many years that have gone by, made certain functionalities break in those apps. So, something that was fine 10/15/20 years ago, are now technical debt due to their no longer being able to run.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • No Rod, you have it exactly right. You expressed it far better than I did

Viewing 3 posts - 46 through 47 (of 47 total)

You must be logged in to reply to this topic. Login to reply