CXO Accent

Kaizen in computer programming

H Krishnan

Programme code can be improved all the time. It does not cost much, and leads to better utilisation of hardware

‘Kaizen’ is a Japanese word meaning small, continuous improvements in the workplace, be it in manufacturing or services. This improvement is measured in terms of various metrics such as tonnes per day, percentage of samples passing quality parameters, average time taken to process a vendor’s bill, and so on.

It usually involves small incremental changes that come by analysing problems and brainstorming, as well as improvements brought about in maintenance operational practices. These changes are generated by people working in a particular area, by their own efforts, and involve minimal or no investment. The improvements take place in small, continuous increments.

For example, cleaning the distributor plate in a cement mill once a shift instead of once a day brought about an improvement of throughput by 1-1.5 tonnes per hour. Operating the kiln inlet fan at 800 rpm instead of 730 rpm improved the oxygen supply and combustion leading to increased clinker output by 2-3 tonnes per hour. Thus, in a factory environment, the scope and practice of Kaizen is tremendous.

Kaizen in computer programming

The same technique can be applied to computer programming. Here it is the analysis of code in a working (meaning one that is in regular use) programme, and rewriting said code with improved logic and data to get improved code. Once this improved code runs satisfactorily in terms of output, one can claim that Kaizen in computer programming has been achieved. Programme modification such as adding a column here or deleting a row there is a user requirement (hence a must) which does not count, though it could be Kaizen for the user. Computerising a manual record is not Kaizen as the activity itself is changed significantly, involves considerable expenditure, and in many cases cannot be carried out by the user himself.

Our IT environment is SAP R/3 version 4.0B, running all the modules except sales & distribution, HR and payroll. The three-tier architecture consists of the database, application server and client desktops running a presentation server. Programmes (report and processing) are written using the ABAP/4 programming language.

Giving Kaizen in programming a try

Methodology: First we needed some metrics to measure the quality and performance of a programme before we could even think of improvement. We brainstormed to identify how the quality of programme code could be measured. After tossing around ‘lines of code,’ ‘number of variables,’ ‘tables defined and used,’ and ‘comment lines (the more the merrier),’ we decided, based on the user’s benefit and perception, that ‘duration of run’ should be the sole measure of performance. We analysed system logs to find out which of the regular programmes were taking a long time to execute. A ledger-printing programme was selected. The entire team went through the code in a single sitting (including the creator of the code). The code was dissected line-by-line and improvements noted.

Programme improvement: (sample observations)

• Tables not used lafA1, Ska1, itab1, itab2
• Fiscal year need not be entered
• Remove group by & sum (Not required)
• Select into instead of move
• To derive opening balance from standard SAP function instead of calculating it with custom code
• To increase occurs clause from 10 to 1,000
• To eliminate (itab) header table
• Remove two loops, remove dr-cr flag comparison

29 such improvements were identified and the code was corrected. In addition to identifying such inefficiencies in the code, the sequence of accessing data itself was changed to improve the hit rate from the database tables. Primary keys were analysed, index files created on frequently-used columns, redundant primary key comparison added in the ‘where clause,’ and so on. After the changes, the new version and earlier version codes were run in the background with same input parameters and their run-time recorded.

The benefits

Average server response time decreased from 1,300-1,400 milliseconds to around 900 milliseconds, and the throughput of jobs increased. In addition, the monthly ledger, inventory runs (normally scheduled in the night in the background) getting disrupted due to long run-time (time-outs, data errors, etc) and consequent re-run during peak hours in the day were eliminated.

Another spin-off of this exercise was that subsequently all programmes under development were initially examined for performance improvements by another programmer as part of Quality Assurance before releasing it to users. Finally, the upgradation of the server was postponed by another year until the workload caught up.

Conclusion

Programme code can be improved all the time. It does not cost much, leads to better utilisation of hardware, and is a good learning experience.

The author is assistant vice-president, IT, at Rajashree Cements. He may be contacted at hkrishnan@adityabirla.com