Mainframe, MVS and zOS Discussion

How do you folks measure the quality of code in your projects? For simplicity, lets assume we are talking about coding in COBOL. What are the things you pay attention to i.e. collect as metrics?

Irrespective of whether the code base is small, medium or large; code is code. What then are the commonalities in measuring quality of code? Deep research has already been done in this area. McCabe's study provides large number of metrics to capture the quality of code. What are the top 10 code quality metrics that you rely on in your projects? How do you capture them? How do you interpret these metrics? What are some of the lead or lag indicators that tell you that the code is good or bad? How do you use them to prevent or solve a problem?

I think it's a complex question to answer - possibly such a measure can easily be applied to open system technologies however for a mainframe, for example, COBOL program, it's tough to define a universal rule for programs which in turn are dependent on Business rules. A review of code by someone with Business and technology acumen had been the key - though I'm open to listen to if other mainframe shops had been following something different.

How do you folks measure the quality of code in your projects?

define quality of code first

Irrespective of whether the code base is small, medium or large; code is code

This statement completely ignores the reality that as the code base grows, the intercommunication between modules becomes more important and more complex. Writing a 500-line COBOL program is pretty simple since there's not a lot that needs to be done (or can be done). Writing a 15000-line COBOL program requires a lot more effort and thought since there will be a lot more happening in that program. And as programs communicate more, the interfaces between them become more important.

Furthermore, what is "quality" in code? You may have a system that runs without an ABEND for months but the user interface is so bad that the users do everything they can to avoid using the system. Is that a quality system? On the other hand, if you have a CICS system that averages 3 ABEND transactions a day (or hour) but the system perfectly handles the business logic and the users love using the system -- is that a quality system?

I agree with all the statements made here. Though these question do come up in our weekly/monthly meetings and some times from the clients too and then I don't know if we can have such a thing in place. Now with the statements posted here so far should I say the 'quality of code' can not be measured??

should I say the 'quality of code' can not be measured??

I think you would be better off saying that "quality of code" is not a measurable metric. You can count fixes per thousand lines of code per year (or month), you can count ABENDs per year (or month) per thousand lines of code, you can count user complaints per thousand lines of code per time period .... If you cannot come up with a way to count something to measure "quality of code", how could you possibly use "quality of code" -- especially to compare one application to another? However, if you determine what you need to measure, that can become a quality of code metric.

This whole issue is called "software metrics" and there is a pretty substantial body of work about it (Google software metrics and you get about 21,600,000 hits back).

Now with the statements posted here so far should I say the 'quality of code' can not be measured??

You can measure something that can be defined

quality on the other side is a very abstract concept ...

how far is <far away> ?

the only thing that might be measured is the compliance of the product with the standards ( once You have defined them )

We do peer review and a senior review some times. If they see some improvement can be done, they help with that. Apart from this we do not follow any rules for the quality of the code. But can there be such rules which a programmer can follow?

There are rules on how to make the code more "readable for the next programmer" though I've observed different programmer follow different styles. One programmer might/might not like the style of the other one, however, as long as the style makes it easy for the other programmer, it should be fine. So in general, there are guidelines but not rules, as such, which are abide by some penalties. Having said that - a specific shop, however, might have some rules and the penalties associated with them for this but I've rarely seen such rules.