# Explained : Measuring Code

Premise:

Measuring system for real world objects and code is different. Virtual system measuring metrices evolved over the years. But are they fit for today’s world?

Code measuring systems and metrices rely on quality and syntax of written code.

With Modern system hardware’s CPU’s speed increasing exponentially every year developers can run codes faster and computation are easier.

So, do we still need to measure the code same way we always did?

Real life measuring system:

In Real life everything we measure evolved from references. Weight, Volume, Height all unit of measurements are based on reference.

How do we calculate Height of 5 Meter?

The International System of Units (SI), commonly known as the metric system, is the international standard for measurement, The International Treaty of the Meter was signed in Paris on May 20, 1875 by seventeen countries, including the United States and is now celebrated around the globe as World Metrology Day.

So, if I know 1 Meter, 5 Meter is five times more, so 1 Meter is pure unit of measurement as per the treaty above.

Derived mathematical measurements.

Derived units are associated with derived quantities; for example, velocity is a quantity that is derived from the base quantities of time and length, and thus the SI derived unit is metre per second (symbol m/s). The dimensions of derived units can be expressed in terms of the dimensions of the base units.

So, for any measurement technique use references or baseline to determine how good or bad something is.

Virtual systems measurement:

There are several established standards in a computer system. E.g. – Memory size or standards unit of measure (MB, GB, TB). CPU speed is measure as number of cycles executed per second in GHz (gigahertz).

That brings me to the point what are the standards for code. Do we really have any measurement systems standards? Are they evolved to keep up with today’s world and should those be followed?

Let’s talk about Code Measuring Practises:

• Code Quality based.
• Code Performance based.
• Develop to Defect Ratio.

Quality based:

Quality based measurement is against standards set using best practices. In the programming world definition of quality is constantly evolving and can vary from market to market customer to customer.

Code Performance based:

Performance of code is to improve user experience, optimize code or computation time can be lower. In SAP world trace, runtime transaction analysis SAT, SE30, ST01, ST05, ST12 helps to measure performance.

Develop to Defect Ratio.

Customer business needs to run smoothly. Every piece of development vs number of defects raised is used to identify how good a code block is.

Measuring Tools:

Any ERP customer in my experience uses several tools and governance to try and control code quality.

1. Governance processes review mechanism of code.
2. Code review tools SLIN and code inspector.
3. Automated testing tools to reduce regression.
4. Defect measurement.
5. Early watch reports.

Even with all the above there are bad code / good code any systems, as the saying goes “Systems are as good as the one who maintain them”. Still human ingenuity is what matters the most when code quality and management is concerned.

Automated systems:

Automated deployment and code reviews are not new anymore, code quality gate extended code inspector is a good way to reduce manual work and reduce errors.

Honorary mention:

HANA Recommendations:

1912445 – ABAP custom code migration for SAP HANA – recommendations and Code Inspector variants for SAP HANA migration

Conclusion:

Let us try to define a system / process to use in measuring code in ERP Systems. For purpose of Simplicity I will call it “Code Measurement Index”.

A code measurement index is simply a point-based system. Averaging in multiple dimensions of code measurement for every application in the system.

This can be a simple customer program in ABAP that calculates this value for you to indicate how good or bad a system is. I use below parameters for this calculation. In this example I am using t-shirt sizing.

Code Lines:

No of lines in a code block / code unit (Code unit can be as low as subroutines and high as the System itself).

 No of Lines Scoring 10 XS 20 S 30 M 40 L 100 XL >100 XXL

Inheritance: Any object-oriented codes measurement should be with number of inheritances.

 Inheritance Level Scoring 0 XS 1 S 2 M 3 L 4 XL 5 XXL

Nested statements: Nested code statements like IF – ELSE block CASE ENDCASE.

SQL Time: X, Y Graph Y being no of records selected X time taken. Curve should be under 30 Degree to receive an optimize performance.

Finally:

Like human intelligence measured in IQ. Code is not very different it’s almost like a living organism build from logic, mutating and evolving over time as we are.

So, measuring code cannot be simply in two dimensions. It has multiple dimensions and multiple parameters.

As systems are becoming more sophisticated and hardware’s faster everyday it is needed more than ever to ensure the code in those systems run more efficiently and easy to maintain.

The metrices for Code quality, performance etc are not going away but they can be simplified as they evolve but it is an ongoing process and different in different organization.

Lastly Keep your processes for code review and quality simple as always simple process always creates intelligent behaviour.

### Assigned Tags

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

Code Review

Think about the size of the company.   Code reviews may/may not be possible.

Think about deadlines and complexity of making the change.  What things can you let through your code review that will not cause performance issues.  You might want to keep a spreadsheet of those times.  But honestly I’ve not done that.

Remember there are “stupid” information/warnings in extended syntax check.  I tend to ignore them.  It is better than commenting every line of code.  Or removing a variable that is actually used.

And there is more…   standard tables vs. CDS view – it might not be the best solution but it might not hurt performance.

Readability, Maintainability and performance issues would be the main reasons I would stop code from moving to production with a tight deadline.  If I have the time, then yes, I would check a lot more.

Defect Ratio:

What do you consider a defect?  That is the question of the day.  A customer would say everything that doesn’t work the way they expected is a defect.

So is it in the code?  Is it in the specification?  Is it that the customer just didn’t give you a full list of expectations?

I think a defect is a bit hard to track.  When we go live, we are fixing things that a lot of the time are not code based.  (But they could be considered code based)

At one time I thought it could be tracked based on short dumps.  Then I found times when the customer and/or analyst did not know the code would run when xyz was triggered in a totally different area than where they worked.

How about the times when originally the code was only supposed to run once a day and was supposed to be pulled in x days?  In other words, you threw together a program very fast because it was never going to be used again.  You find they are running the program 3 times a day for the rest of the year…

Here’s my conclusion, it is hard if not impossible to track how good someone does their job based on automatic criteria.  In fact, I’ve found that it can make things harder, because the data can be misleading.  The smaller the company the harder it becomes to track.  Why?  Because a employee is required to do many different things.   The larger the company, the easier it becomes to separate jobs.   But still it comes down to what is considered a defect, timelines, and internal employees compared to outside consultants.  Everything is a factor that can not be measured based on a program because so much of it can’t be defined.

Interesting blog - I'm sure there will be a lot of different opinions.

Tapodipta Khan
Blog Post Author

Valid points:

Couple of suggestion that may help. Idea is to have a measurement system that is standard and can be easily followed.

1. Customizing the code inspector and ABAP test cockpit against requirement specific to companies guidelines. Check only what is relevant to the company. Few other tools along with this like SONAR and quality gate will help in reducing time taken for non value added manual checks.
2. Code to Defect ratio is more useful when defects are tracked out of Review. This can be automated even with ABAP codes in system.

Neat presentation... clearly explained Thanks