Coding for Clarity: The Hidden Costs of Code

/Coding for Clarity: The Hidden Costs of Code

Coding for Clarity: The Hidden Costs of Code

By |2019-02-22T11:54:59-04:00February 25th, 2019|Enterprise Resource Planning, Software Development|1 Comment
  • Coding

There are thousands of ways to code a solution to meet any business requirement. From a business perspective, as long as the code performs the required function it works. Code is a living construct in that it is likely it will have to be maintained more than once during its lifespan. The actual code written to satisfy a business requirement may be poorly structured, difficult to read and contain overly complicated logic; and there is an inherent cost in maintaining such code.

I learned to code at Van Zyl and Pritchard in South Africa. The intensive course was conducted over a three month period and taught us to program in COBOL. However, the language wasn’t important; what was most important is that they taught to write structured code that was easy to read and easy to maintain; recognizing that code would be passed from programmer to programmer.

When programmers first started to code the code they wrote was unstructured. At one client in the 80’s I had the opportunity to work on a program written without any structure. In order to understand the flow of the program, I constructed a 17-page flowchart. I had to invest days in trying to understand the code before I could make the change. All the time spent understanding the program increased the cost of maintaining the program.

There are a couple of aspects that make a program easier to understand and therefore easier to maintain. In truth, it is easy to write code that is easy to maintain if one understands the guiding principles which in themselves are simple. However, the programmer has to be disciplined and see the value in creating code that is maintainable.

Writing code that is easy to read and understand

To create code that is easy to read and easy to understand the developer can employ many simple techniques such as: indentation, comments, numbering form routines, applying a consistent standard to naming of variables, deleting unused variables, deleting commented out code, declaring all variables at the top of the program (not interspersed in the code).

Although these techniques are simple they make a huge difference to the person inheriting the code. After I completed the course and started to program I became a little lax in commenting my code because I wasn’t 100% convinced of the benefit of commenting code.  I was working on a program and was asked to switch to another program that now had higher priority. Two weeks later I returned to the original program only to find I could not remember why I had made certain choices. From then on out I made sure I commented on my program, paying special attention to any decision-based logic.

Writing code that is easy to maintain

One of the tools for writing code that is easy to maintain is modularization. If a section of code is repeated, that is to say, it is essentially performing the same function it should be put in a form routine (method in object orientated programming, function in JavaScript), accepting input parameters for the variables that are changing. How does this help? I’ll explain by way of an example. A program I was maintaining created subject lines for workflow work items as one of its functions. The same piece of code was repeated 12 times in the program with small variations. I was tasked with adding date and time to the subject lines. I would have to make 12 changes, instead of one. I took it upon myself to modularize the code and made the single change in the newly created form routine. When I tested the code I only had to test one scenario to ensure the date and time appeared, instead of testing 12 scenarios.

Another reason for modularization is to break lengthy sections of code into shorter routines. This assists in debugging code when troubleshooting; when a developer has debugged a routine and found it to be error-free, they can bypass that code in future passes. It also makes the program easier to maintain if there is some thought behind the modularization, for example having each module perform a specific task in a sequence of tasks. For example, a report might be modularized along the following lines, fetch data, prepare data for printing, print data.

There other ways in which a programmer can ensure that their code is as simple and easy to maintain as possible. Having maintained code for 30 years I can tell you that these simple practices are not followed. This increases the cost of the initial development and testing as well as the cost of any maintenance and subsequent testing of the code. Of course, this cost is hidden, buried in the expensive IT bills that have become the mainstay of modern enterprises.

One way to reduce IT costs is to keep a small code footprint. Clear Software leverages existing API’s from ERP software and our tool ClearWork comes with extensive functionality built in that reduces the need for coding and allows for a drag and drop approach to screen design along with minimal coding. The same is true of ClearProcess; a lot can be achieved with a minimal code footprint.

About the Author:

Derick Logan
Experienced SAP Technical Consultant with a demonstrated history of working in the machinery industry. Skilled in Business Process, SAP Implementation, Electronic Data Interchange (EDI), IDoc, and SAP ERP. Strong information technology professional with a Bachelor's Degree focused in Bachelor Of Commerce/Accountancy & Commercial Law from University of the Witwatersrand.

One Comment

  1. Avatar
    Eileen February 26, 2019 at 10:32 am - Reply

    Great article, Derick! I found some really useful and tangible information.

Leave A Comment

This website uses cookies and third party services. Please review our privacy policy for additional information. Do you consent? Yes