Code quality – those two words are something that everyone – literally everyone involved in the application development and delivery process care ( fear ?) about. The other interesting aspect is – depending on who you talk to – business analyst or developer or manager or project manager or tester or build/install guru or release manager or operations – you will get a different definition or perspective of code quality – but one thing that is common is everyone sees it as a measure – measure of good or bad. A business analyst measures it in terms of the code delivered against the requirement specification, a tester would measure it in terms of the number of defects or failed tests, a project manager would measure it as risk etc. The measure is really critical and is an indicator of how well things are shaping up.

Now, in the changing world of lean and agile development of delivering in small batches, continuous integration and testing – where the key word is shift left – there is a need to complement the code quality measure with a best practice of writing quality code. So what does writing quality code entail ?

The start is to understand the need or requirement, and then to document the need, break it down into manageable but meaningful pieces. Then the critical phase of development – writing code for the stated set of requirements. Traditionally – this phase involved writing code, building, running and/or debugging the code to ensure it works – i.e no abends – and then transfer it to the test team – address any defects opened by the test team and repeat the process. To really shift left and deliver quality code – its not enough to ensure the code works in a couple of different paths by running a transaction or a batch job with different set of manual inputs, the key is to automate the process of running the transaction or batch job with different sets of inputs in a repeatable fashion – popularly known as ‘automated unit testing’. Then measuring the effectiveness of the test by gathering the code coverage results for each test and combining the coverage results to get a comprehensive view of how much of code is really being tested and adjusting based on that information is a critical aspect of writing ‘Quality code’. One more aspect that is often ignored as part of writing quality code is code review. Code review is a process of validating the code against a set of organization established coding rules or standards, the aim of which is to ensure the code being developed is easy to read, maintained, not complex etc. This is a mind set or culture change that organizations have to drive and acknowledge that writing quality code will result in good code quality.

Now that we have established the Why & What – next blog would dive into the How of writing Quality code…

1 comment on"Code Quality vs Quality Code – Venkat/IBM"

  1. IBMRationalAssetAnalyzer February 17, 2016

    Newly announced! Supercharge your development and delivery with Application Delivery Intelligence (ADI)

Join The Discussion

Your email address will not be published. Required fields are marked *