Skip to Content
author's profile photo Matthew Billingham

Quality code is cheaper

* Please Login or Register to Comment on or Follow discussions.


  • Jun 02, 2019 at 04:57 PM

    i'm far from being a design thinking expert, but is this a counterargument to this: or is there some kind of middle ground?

    • Jun 02, 2019 at 07:36 PM

      Agile may be the answer, but I think it's yet to be proven.

    • Jun 05, 2019 at 12:09 PM

      Why do you say it is a counterargument?

      Quality doesn't mean up front design and large frameworks. It's a mindset. It means continuous improvement and refactoring. When there is change, don't just add the new feature with the dreaded flag parameter and IF statements, but take time to adapt the system.

      • Jun 06, 2019 at 10:03 PM

        i have noticed some large organizations have 'discovered' agile and try to rejuvenate themselves through it. in many cases, it seems to be a fad and where a methodical approach to designing, building, and supporting software products have ensured high quality in the past even if perceived as a slow and bureaucratic process.

        with many interfaces baked into specific releases it may be really hard to let go of waterfall and start sprinting to nowhere and not necessarily after more agile competition. hence, the intent of my original question, what would be a middle ground or measured approach to ensure high software quality?

        • Jun 07, 2019 at 11:27 AM

          OK now I understand your comment. But I think you're mixing the agile principles with how it is run and managed. I've worked with good and bad agile projects and there's a world of difference. Some will cherry-pick agile concepts that suit them and think they'll reap all the benefits. Bad agile is worse than waterfall (and don't get me started on bad waterfall).

          So no, IMHO agile vs waterfall has little to do with the original quality discussion, it's just a means to an end and the value of quality applies equally to both. It's not what method, but how you apply it that matters.

          From my experience, agile done well is better suited for quality as many quality-oriented development practices are fundamental to the process. If you choose to ignore them then agile won't bring you all the benefits. If you choose to bring them into waterfall, then that's also great. I don't see a 'middle ground', you can focus on quality regardless of methodology.

          • Jun 13, 2019 at 09:46 AM

            To put it short: A new method does not compensate incompetence. If your team is not skilled, agile brings no benefits, at all.

            Luckily we have a skilled team. So the shift to agile didn't hurt to much ;-). You have to get used to the tool chain. After the first user acceptance test the benefits appeared. We could implement their improvements/feedback, right away and didn't have to scrap tons of careful waterfall planning. Of course you shouldn't loose your main goals out of sight.

  • Jun 12, 2019 at 10:29 PM

    My late grandma (and my mom) always said: "the lazy ones walk twice, the cheap ones pay twice". As someone who tried too many times to carry too many items in my hands and ended up dropping something and having to clean up and to walk 2-3 times eventually, I can confirm. :)

    In ABAP world in particular, I find this quote from the article to be painfully accurate:

    "Progress is rapid initially, but as time goes on it gets harder to add new features," he writes on his personal website. "Even small changes require programmers to understand large areas of code, code that's difficult to understand. When they make changes, unexpected breakages occur, leading to long test times and defects that need to be fixed."

    Few months ago I had to work on a file interface program to make multiple changes. I was hoping to find at least a clearly labeled routine where the data was mapped to the file but no such luck. After briefly scanning the monolith of 10,000 line report I started to feel dejavu, as if I was scrolling through the same code over and over.

    Apparently this report was worked on by a few generations of developers. The first person to make changes apparently was afraid to touch anything, so instead of just adding a few fields to an internal table they created a new table, which included the existing fields and some additional ones. Then the next person came in and was probably like "what the heck?" but I guess they did not want to touch anything either, so here we go again, third table with more fields. (Mind you, not even a single MOVE-CORRESPONDING used!) At that point the program was pretty much FUBAR and looked like that creature from the finale of The Leviathan horror film. I could almost hear it wheezing "kill meeeee".

    Of course, I'd rather shoot myself than add a table number 16 to it, so I started to untangle the whole mess, removing and consolidating data and renaming routines as I went. (There was no time for a complete rewrite.) Yada, yada, yada, I bet all the previous generations of developers got a pat on the back for completing their assignments so fast but, in fact, they just passed their "technical debt" onto me. Good thing I had a week to spare to sort out most of the mess. And, of course, as I touched the global variables, the program started to crumble like an old Dodge pickup held together by rust and dirt. So yeah, quality code is cheaper indeed. But the problem is with making the consultants and managers to care.

    • Jun 13, 2019 at 05:13 AM

      That sounds like broken window syndrome. As soon as one window in an abandoned building is broken, the rest will quickly follow. As soon as one programmer does something bad to code, the next programmers won't see any reason to fix the quality.

      I was quite happy yesterday. I'm adding some new functionality to an existing program (that I wrote!) - adding a simulation mode. All I had to do was extract an interface from the class that does the db update, create a simulation class implementing that interface, and slightly modify the calling code so that the instantiation was either real update or simulation. And it worked. The great thing is that the code that uses the interface is really complex, but I've not had to change the logic so the chances of it "just working" are fairly good, and the chances I've broken existing logic are fairly low.

    • Jun 13, 2019 at 07:52 PM

      "But the problem is with making the consultants and managers to care" - applies to majority of things in our industry , sadly.

      • Jun 14, 2019 at 07:24 AM

        Not just our industry. One of the big companies near me (not IT) is reorganising. In the process, some people will be made redundant - even though those people have a wealth of knowledge and are widely regarded as excellent in their expertise. Without them, the company just won't run as well as it could. But the powers that be don't really care about anything other than their bonuses this year and next. (For "cutting " costs).

        • Jun 14, 2019 at 10:42 AM

          Good thing you said "not IT", else I would have thought you were talking about SAP.

          At least they saw sense and re-hired/reinstated (or whatever) some of their redundees.

  • Jun 28, 2019 at 01:59 PM

    One of the oldest stories in the book ;-P

    IMHO both, Quality Code and quick-and-dirty-Spaghetti-Code have their right to exist. I've written stuff within a couple of hours with a quality that is questionable at best, which, however, still works stable and without any fault 8 years later. Though, it never required any maintenance, and that's the sticking point. If the application/function/project is something that has to adapt over time and "grows", I'm 100% with the El Reg Article. If it doesn't, then not necessarily.

    The challenge, in my experience, is to make the right call when looking into your crystal ball, where the time investment for quality coding is best...well, invested :-P

    If it goes wrong, you can still call this guy, though:

    • Jun 28, 2019 at 03:19 PM

      The question is whether your guesses at kwik-dirtee-cheep or quality-clean-expensive are correct often enough to shift the ToC down.

      Anyway. Next year, we'll all look back at our coding decisions with 20-20 vision. ;-)

    • Jun 28, 2019 at 03:38 PM

      There's also the complication of programmer experience. The quick-and-dirty code that I write today is much more stable and (usually) much simpler that what I might have written at the beginning of my career (way too long ago). As the skills of the programmer evolve, quick and dirty is filtered by what our experience tells us works well.


      • Jul 01, 2019 at 10:02 AM

        Indeed, well said. I gotta quote the Tao of Programming here, it fits perfectly :-P

        - There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure." -

      • Sep 16, 2019 at 07:44 AM

        Very good point with the "even quick-and-dirty gets better with experience" !

        I try to make it *easy* for me to write good quality code, e.g. by investing (creating + improving) in templates.

        I wrote about that here: .


  • Sep 13, 2019 at 09:26 PM

    Came across this today again while browsing CC. As a more positive example: today I was working on a program that, thankfully, has been already made mostly "technical debt free" by my colleague. He worked on it just a few months ago and updated whatever was possible according to the current guidelines. Now thanks to his effort it's simple for me to make a change because there is just one SELECT... JOIN instead of dozens FAEs and the code is easily readable. So his effort is already paying off and I'm sure will pay for itself many times in future. All we needed to do was to start making things better.

    • Sep 16, 2019 at 06:09 AM

      I always try to leave code in a better state that I found it. Even if it's just removing pages of commented out lines. My latest approach is to move any calls to SAP functions or classes, and any db access, to a separate class (defined wrt to an interface). Then I've a chance of writing abap unit tests. I'm a bit under-utilised at the moment, so I have time.

    • Nov 29, 2020 at 11:53 AM

      Jelena Perfiljeva and Matthew Billingham - True story at SAP TechEd 2012 - I was in the session where the father of ABAP Horst Keller was giving a presentation about the future of ABAP and he made a HUGE point about using joins vs. FAE's (I'm using your term - I call them artificial joins but I think we are talking the same thing) and then the comment period started. You would have thought that Horst had told them that the earth was flat and developer after developer went up and said that he was wrong. I like to tell the story about a man named Jim Gray who revolutionized SQL databases and invented granular locking which made FAE code that was necessary in the 1990's unnecessary (I had to use the same technical for a VAX/VMS system and I HATED it - it was because SQL databases at the time did NOT handle deadlocks and lock conflicts and thus that is why SAP did what they did with internal tables and READ TABLE with keys. Sad to say that Mr. Gray lost his life in 2007 when he went to pay his respects to his mom and never returned but I digress - his story can be found at Jim Gray (computer scientist) - Wikipedia

      I was taught in college to use joins because I took courses in database design and fundamentals. When I started with SAP in 2006, joins were very limited and thus the use of internal tables to "simulate them". Fast forward through various SAP ABAP versions and joins are now the standard - but you'd never know it from reading code from SAP nor most SAP programmers that I have run into.

      Old habits die hard and when courses like Advanced ABAP make the blanket statement "the more memory your program uses the faster it will run", I just cringe.

  • Add a comment
    10|10000 characters needed characters exceeded