Whole code awareness

Busy software developers tend to think of refactoring as a luxury activity, and separate from writing new code or fixing defects. At first glance, the latter two activities clearly contribute to why we write software — to get new, working functionality from hardware — while refactoring, by definition, doesn’t change the software’s behavior at all.

But if we recognize that every code change or addition may affect both the dynamic behavior (what the software does), and the static behavior (how easy it is for the developer to modify it as desired), then all three code-change activities come together. Every code change, whether it’s refactoring, new code for new feature, or changes to fix a defect — and no matter how small a change — is a change to the entire codebase with the purpose of increasing its value.

This mindset is what motivates code quality engineering practices such as in-person design and code review, static analysis, and automated whole-system regression testing (including load testing and robustness testing). As well as, of course, refactoring!

And while time and resources for these activities can be planned as part of any software development methodology, it seems easier in Agile. Include all these activities regularly in sprint tasks per user story, evaluate them all in planning based on their size (cost) and their benefit (value), and get them done regularly. Apply this whole-code awareness, and watch defects decrease and velocity (and enjoyment) increase!

—

Thanks to Will McKinley for the post Code Refactoring – Dealing with Legacy Code that made me ask myself what are the differences, and similarities, between refactoring and other types of code changes.

Advertisement