Better Code Understanding & Analysis

Overview: Chapter 8 of the Building a Better Software Delivery Platform podcast series covers application and program analysis. Understanding how programs interact with each other has great tactical and strategic benefits, including the reduction of technical debt and minimization of time spent training new developers.

 
I’ve seen several references to “technical debt” lately in podcasts, articles, blog posts and other resources. So, as Rick Slade was talking about application and program understanding in Chapter 8 of the Building a Better Software Delivery Platform podcast series, the notion popped into my head.

Advantages of Modern Tooling

Rick mentioned that many veteran developers have written their own code to create tools to try to measure the impact of changes they were making. Modern impact analysis tooling not only removes that burden, it creates easier to learn and more consistent processes for new developers as they come on board. Charts and other graphical representations of how code interacts also help newer developers see the effects of their code on applications that were created before they joined the organization.
 

Topaz for Program Analysis Detailed Information on Program Calls | Compuware

Detailed Information on Program Calls in Topaz for Program Analysis

This brought back memories of past jobs where I was given custom tools created by my predecessors. These programs often were successful at the specific job they were supposed to do but failed to keep up with updates and changes that rendered them only partially useful. The fact that the original authors of these programs weren’t necessarily available for training or guidance meant that whatever benefit the programs originally provided was lost and I was forced to create new methods to get the job done.

Assisting with Knowledge Transfer

Then there’s the issue of knowledge transfer, which is especially acute for mainframe enterprises experiencing a mainframe brain drain. Whether someone is working with a custom program or with a full application suite from a trusted vendor, new hires need to be trained. And if you’ve been doing the same job the same way for years, it’s natural to expect that you won’t think of every detail when training someone new. In some cases, you may only have a week or two to transfer decades of experience in operation, shortcuts, best practices and real-life if/then situations. As Rick points out in the podcast, modern impact analysis and discovery tools allow for the creation of a central repository of reporting that can be used to train developers and act as a reference resource. And the ability to create graphical representations, again, is key. Rick explained,

Passing along a picture is certainly going to be easier to understand for the new developer than trying to explain it textually or verbally.

Unused Code

One other key point that struck me was Rick’s discussion of technical debt from code that simply isn’t used anymore. I’ve personally seen it countless times; new code is added or perhaps parameters are changed, and older code is left untouched. Sometimes this is done for the sake of expediency, with developers working under a tight deadline and not wanting to take time to remove unused code, but it also may be done because of a fear of unintended consequences.

I’ve seen this not only with code, but with files, as well. A program that references a particular file may be modified for different purposes, but still looks to reference an obsolete file that hasn’t been used in years. The file system is cleaned up, obsolete files removed, and suddenly that program fails because it can’t find the file it is meant to reference. This leads to a paralyzing fear throughout the IT operation where code can’t be changed and files can’t be deleted because there’s a chance they may affect other unknown files or programs, creating bloated programs full of unused code and storage capacity wasted on unused files. Plus, as Rick pointed out, “Technical debt consumes time because potentially we’re building test cases and testing code that has no value.” A good understanding of how programs interact and clear analysis of the impact of any changes can help reduce all of these issues.

To hear Rick’s discussion of application and program understanding in its entirety, or to catch up on past episodes, visit www.compuware.com/goodcoding. And be sure to check out Chapter 9: Code Quality and Security to hear Rick’s conversation with special guest Nicolas Bontoux, Vice President of Marketing of SonarSource.



The post Better Code Understanding & Analysis appeared first on Compuware.

Read the original article

Related posts

Leave a Comment