Skip to Content

I have both a dog, and some code.  The logic behind determining a dog’s age is something like this:

When dogs are one year old, they are really still kids, still playful and inquisitive (although somewhat unlike sullen human teenagers). They’ve matured more rapidly than  1:7 (dog-to-human years) but that changes.  By 18 months, a dog has reached physical maturity.  After about age 6, a dog starts to mature more rapidly than a human.  Some dogs reach the ripe old age of 15 (which has been compared to a human at age 105).

But what about your code?  I have to admit, sometimes I come across a program written in 2004, and I think ‘Whoa!  You robust piece of code!’.  Other times, my heart sinks when I see something written in 2002.  Wow, that code is on its’ deathbed, it just doesn’t know it yet.  It’s about to take a dirt nap.

So how DO you calculate the age of your code?  If you think about your code’s birthday as the first year it is in production (after all the birthing mess, minor corrections, etc) At what point do you consider this code to be adult – more or less functioning as intended, not still hiccupy like a kid, but probably with quite a few good years left until retirement.  And when is code allowed to retire, to gently ride out the golden years in a cabin by a lake?

BUT.

Perhaps you don’t have a retirement system for your code – so it lurks out there, unnoticed, until one day you stumble across it and can’t believe what you are seeing. Should it be moved to a museum or something?  (or a mausoleum?) 

AND.

Are upgrades the code equivalent of mid-life crises? Is that when your code wakes up, realizes it can no longer go on quietly behaving, and runs out to buy a Porsche? 

SO.

I have no answers, only questions.  I do see that the programs written in 2002 are probably overdue for that dirt nap.  I suspect that code written in 2007 is still pretty healthy, and will probably hold on for a few more years.  I see code written in 2011, and I think ‘Oh, isn’t that adorable?  It’s so innocent when it’s that young!’.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Gustavo Sanchez
    And here I would say code is ageless as long as the initial conditions don’t change the good old chap is as good as the day he was released into the wild.

    we don’t change all the code all of the time rather we focus our attention on a few that are either misbehaving or that we want them to do more.

    (0) 
    1. Susan Keohan Post author
      Hi Gustavo,
      Of course, we can’t change all the code, all the time.  And I guess ‘as long as the initial conditions don’t change’ is about the best life a program could get… but how often is *that* really the case?
      Often, I think some programs just run quietly in the background so that they can keep on being useful with nobody being the wiser 🙂
      Thanks for the comments!
      Sue
      (0) 
      1. pierre buret
        Interesting question really, although code is pretty much ageless (it’s even better than aging gracefully!): my guess is that a lot of the oem SAP code is pretty old (eg fixed asset module). A lot of the Unix Kernel is probably not that young either.

        As for custom developments… as long as the code was properly written and/or has not been heavily modified, it really does not matter how old it is.

        A few more remarks:
        – I will argue that some of the old timers were master coders, having been used to working in tight conditions (limited memory, etc…) and so the code developed a few years ago is oftentimes not only robust but pretty efficient too…

        – Any new compilation will essentially ‘refresh’ the code (the equivalent of a face lift if you will) so what you see (ABAP) might be the same but underneath (microcode), things change

        – Your question brings another interesting point i.e. how much of the old code (same for batches) is still seating there, doing nothing – probably quite a bit – I guess in many cases end users stop using the programs before the code becomes obsolete

        (0) 
        1. Susan Keohan Post author
          Hi Pierre,
          Thank you for the thoughtful comments. 

          Yes, if we knew when our users stopped running the programs, then we could retire them.  I don’t always know that though.

          So what would you think the Unix Kernel is, in dog years?  🙂

          Cheers,
          Sue

          (0) 
          1. Andrew Baines
            I think of my code as the era in which it was written, rather than the number of years.

            There was the era of assembler (6502 since you ask – yes, I’m that old)

            Then the era of Forth/Pascal/Fortan and a little Cobol.

            Then there were the dark ages where I didn’t work in the tech sector – wrote a little QBasic for personal use.

            Then some Visual Basic 5/6 – doing presales, I dread to think what that code looks like now.

            Then Active Server Pages – all that mixing of business logic and UI – some of that is still in use. Code looks awful, but works a treat.

            Then moved to VB & .Net – my first Object Oriented code – a strange mixture of procedural and OO while I got the hang of it.

            Finally, the enlightenment, with proper OO and C# – mostly web.

            So, for me, code ages as expected coding standards change and user expectations shift.

            (0) 
            1. Susan Keohan Post author
              Oh, now we are going in the way-back machine!
              Frankly (and somewhat happily) some of my earliest code has been retired – for a couple of decades at least.  I started using BAL on Olivetti Business Machines, and we had a 32 character, one line display.  We had (at most!) 32K memory to write programs in, and most times had to overlay the start of the program with new code to complete the process. 
              Then I moved into the brave new world of COBOL.
              Ha!
              (0) 
          2. pierre buret
            Unix age in dog years ? 4th or 5th generation since the first iteration (Multics) dates back to the late 60s. I don’t know if htere are too many people still around who are familiar with the coding of Unix kernel and can tell which part is stil the original; in the Linux community, you could probably find coders who know what part is still close to the original (and that would be over 140 dog years then).
            As far as finding what programs are used or not… Solman Solution documentation (what used to be called RBE=Reverse Business Engineering) could tell you what program/transaction was used over a period of time (same with audit log) so all in all you might be able to reconstruct a list of (custom) programs that were executed. Alternatively, if you went through a Unicode upgrade and the old programs were not converted, you could easily flag the non-unicode programs as being unused. there might be other (better) ways to find out what program is unused but those 2 solutions are the first ones that come to mind
            (0) 
  2. Peter Langner
    … let me try an answer… In my opinion there are two situations, when (ABAP-) Code gets old when

    1. It has been changed many times by many people, were some them lost the overview of what this program is supposed to do. You find unused subroutines and variables in the programm. This is what you call “spagetti code”. I usually reimplement the code and eat (=delete) the spagettis.

    2. The used concepts are out of date. Code were  e.g. ABAP statements is used which (according to the ABAP docu) should not used any more … If it is not spagatti code, I give honor to it and maintain it in the style it was written years ago, to keep it in the old feasion style.

    Peter

    (0) 
  3. Andrew Barnard
    There is some very old code in the SAP ECC system – some of which came from R2. Still going strong – in the sense that it is still fit for purpose.

    Perhaps it is more a case of maturity? There are some old people that are still immature – and some young people full of wisdom.

    Perhaps we should judge code not on age but how well it does the tasks it was meant to do. And on that criteria – there is a lot of both old and new code that would fall short of the mark.

    (0) 
  4. Otto Gold

    Hi,

    nice thoughts. Maybe we could get hold of some SolMan guru (or guruette) that could explain us – the not(-that-much-)-SolMan-enabled-grey-haired developers what`s out there for us in Custom code management.

    Cheers Otto

    (0) 
  5. Sap Guy

    I see code written in 2011, and I think ‘Oh, isn’t that adorable?  It’s so innocent when it’s that young!’.

    I know the feeling 🙂 .

    When I see code written more than 10 years ago I cringe. Can I still use that function, I wonder? What side effects it might have? Shall I trust it?

    But for a function written in 2010 for example I feel safe, and I am so happy to have found it and use it in the code.

    (0) 
    1. Susan Keohan Post author

      Hi SAP Guy,

      Thanks for the comments – in particular I feel very lucky when I find a BAPI to use – but then I wonder if I should go back and try to retrofit to all the programs that use ‘older’ functions!

      Cheers,
      Sue

      (0) 

Leave a Reply