http://www.perlmonks.org?node_id=518354

In 2005 a whole batch of new Perl titles were published. My favorite among them is Perl Testing, by Langworth and chromatic (with HOP a close second). At the beginning of chapter 3 (p. 39) the authors write:

All the normal rules of programming apply to tests: stay organized, reduce duplication, and don't take on more technical debt than you need.
"Technical debt"??? I've never seen this term before. I have a vague sense of what the authors mean by it, but for my edification: what are common examples of "excessive technical debt" in the Perl world? Tied variables? Lvalue accessors? Source filters? Or is it something even more mundane?

Needless to say, I'd love to read a meditation or two on the issue of Perl-world Technical Debt (hint ;) ).

the lowliest monk

Replies are listed 'Best First'.
Re: Technical debt?
by dws (Chancellor) on Dec 21, 2005 at 17:22 UTC

    "Technical debt"??? I've never seen this term before.

    See TechnicalDebt for some background on the term.

      See http://c2.com/cgi/wiki?TechnicalDebt for some background on the term.

      And bless Mr Cunningham whoever for coming up with such a wonderfully productive metaphor. I've found it a very effective tool in explaining to non-technical people why spending a little now to stay out of "debt" is better than the alternative.

      Thanks!

      Boy, I wasn't even lukewarm on that one!

      the lowliest monk

Re: Technical debt?
by BrowserUk (Patriarch) on Dec 21, 2005 at 18:01 UTC

    I prefer the balance shown in this reference to some of the others I found.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Note that if you follow the link to Martin Fowler's blog there is another smaller wiki entry that adds flavor as well. I usually think of technical debt as a risk run by the usual policy of 'Make it run first...', but a risk I usually live with.

      --hsm

      "Never try to teach a pig to sing...it wastes your time and it annoys the pig."

        I followed most of the links from there, including that one and found a lot of interesting stuff. I think that some people have taken the money analogy a little too far, and many of them miss one quietly stated but very important point from Martin Fowler's blog entry:

        The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively.

        Another analogy that sprang to my mind is that balancing technical debt on legacy code is a lot like running an old car. There comes a point where it no longer makes sense to properly maintain that old banger with new parts, at which point patching it up and 'making do', till you saved enough to fund a replacement can make sound economics.

        There is also another floating around in my brain about not shelling out for a infra-red grill, convection and microwave combo-oven, if all you are ever going to do with it is defrost a few steaks and zap some left overs--but then I remember the behemoth that sits in my kitchen gathering dust, getting use one or twice a week :)


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.