Cirdan Group Blog Refactoring and Risk Mitigation

As a Certified ISO9001:2015 firm and leading provider of Independent Verification and Validation (IV&V) Services since 2003, you can assume we're well-versed on risk mitigation and what quality practices improve project performance and outcomes. And as practioners of lean development methods, we advise clients to pay attention to items with the highest potential impact to their programs. Not too much, not too little, just focus on the important stuff. In most enterprise system, we advocate periodic refactoring as an essential practice to achieving software health. But refactoring efforts aren't exactly exciting, it's like brushing your teeth, we do it for our health, but we can't get too many people excited about it. But that is a mistake because poor code quality is highly risky, it destabilizes system performance and builds up technical debt that over time is horrifically expensive to fix. And that matters a lot, especially to management teams. Within larger systems, and especially those developed using Agile techniques, we have more programmers, and more changes being introduced to code. More changes result in more code breakage, more bugs, poor syntax and inadequate code documentation. So, what do you do? Isn't this a problem for the next guy that works on your code? Sorry, but no. As IV&V practioners, we run into resistance from management and development teams who fail to really understand the wise investment in regular refactoring. Agile teams are already busy and stressed during sprint cycles that never feel as long as they need to be. No time for refactoring. Management teams don't want to spend development dollars on activities that don't appear to add functionality. But good project practioners understand that regular refactoring is a best practice in software development which adds significant value and quality to an application. Readable, maintainable code runs better, more efficiently and lasts longer. Period. So, plan to periodically refactor, but only as much as you need to clarify any problems with the code, to better describe how the code works, to help simplify any changes or fixes... and no more. We have a couple of suggestions; • Apply Lean to refactoring. Write and enforce some code syntax standards because your system is vast, has outsourced teams and everyone is writing code in a different manner. You will undoubtedly find that that your development teams will welcome some refactoring requirements if you welcome their suggestions and work with them to ensure requirements will not be too cumbersome. • Focus on the refactoring standards that can have the most impact in your organization. Is it the code syntax quality? Is it the fixes? Is it only the changes? Whichever it may be, zoom in on only the most impactful ones and call it a day. It will take a little more time up front as you research where the majority of your risk lies but once that's done, the refactoring techniques will just become part of your everyday operations.