Skip to Content
avatar image

Quality code is cheaper

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

19 Comments

  • Jun 02 at 04:57 PM

    i'm far from being a design thinking expert, but is this a counterargument to this: https://agilemanifesto.org/principles.html or is there some kind of middle ground?

    • Jun 02 at 07:36 PM

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

    • Jun 05 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 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 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 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 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 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 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 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 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 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 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 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.

      -Dell

      • Jul 01 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." -

  • Add comment
    10|10000 characters needed characters exceeded