Revisit, Review — Why (and When) You Need a Code Audit
After code has been written and gone live in a program, its developers should just get used to the way it works. Time after time, it’s been suggested that code should never be rewritten, from Joel Spolsky’s now-infamous article “Things You Should Never Do” to contemporary bloggers like Sérgio Serra. However, just because code shouldn’t be rewritten from scratch doesn’t mean it won’t require updates. But many software companies struggle with when to audit their code — so, what are programmers to do?
Audit Code Before Release
Programmers can easily find themselves too immersed in writing code to catch potential problems themselves. Code written by an individual developer or small development team may make sense early on, but as changes or patches are implemented along the way, it may become nearly unintelligible to outsiders. That’s why it’s a good idea to have outside consultants perform code audits, especially for initial program releases. Although your code may work just fine, external auditors may be able to find potential stress points and future compatibility issues that can be addressed proactively, improving the longevity of your code.
Audit Code When You Need to Update
Anyone who has a mobile device with automatic updates turned off knows how often developers update their apps! And updates are usually pushed for a few reasons: either because bugs are discovered or because additional features have been added. For developers, both reasons require code to be revisited and updated. After the first few updates, code for many applications should be solid. However, if an app is successful, it will be revisited, revised, and updated for years after its initial release. Through all of these changes, code can get messy, potentially causing future errors. An external audit can offer recommendations for how to clean up your code, anticipating issues before they arise — and it may even make your source code easier to edit moving forward.
Audit Code When Compatibility May Be Compromised
The third reason an app or a program may need to be updated is compatibility. Because developers are often given early releases of new or updated operating systems prior to public release, this creates an excellent opportunity to perform a code audit. Updates to an underlying operating system are far less frequent than bug fixes or feature additions, but these changes can also be far riskier. Countless programs and mobile applications are abandoned by both developers and users when a new OS version is released precisely because those programs and apps are no longer compatible. If developers want to ensure the longevity of their projects, they should consider a code audit with potential compatibility issues in mind.
Audit When You Inherit Patched Code
Often, when an end-user has a problem with a program, website, or app, there’s a known workaround. Even after the issue is addressed by technical support, users typically aren’t interested in what the problem was or how it was resolved — as long as it works for them, everything is fine.
While this thinking is pervasive among end users (as it should be — there’s no need for average users to be concerned with code), programmers don’t have this luxury. Just because code works doesn’t mean everything is fine. Every developer has, at one point or another, inherited code that seems precariously held together. Usually, development teams believe code like this shouldn’t be touched because it “just works” and nobody knows why. But poorly-patched, misunderstood code is a time bomb. At some point, it will fail, and, by the time everything is fixed (a longer amount of time than usual, since developers have intentionally left it alone), users may have already moved on. That’s why when it comes to patched code, audits are a must.
Audits can be time-consuming, but it’s imperative that when you launch your program or app, it works for users and behind the scenes. This will not only give your project the best chance of success, but will also ensure future upgrades and patches are easily implementable. Without clean, workable code, revisions can be even more complicated and time-consuming, resulting in avoidable losses.