The Pain of Breaking Shit to Make it Better
Often, one must break their most valued accomplishment to improve. Athletes do this by constantly striving to better their old records. For Technical Teams, this is represented by the very software they are most proud of. However, to truly improve in life or code, one must be willing to break what they have worked so hard to build.
The process of taking apart a prized accomplishment is painful at best. However, the result can be life changing. Case in point is the line-by-line code audit. Even for seemingly perfect systems, this process of rewriting and removing code dramatically improves quality.
A code audit is a line-by-line analysis of an entire application using a manual and/or automated process. With the knowledge gained, the team removes and rewrites all of the code that is less than perfect. The definition of perfect is specific to the project.
For example, a large client we will call Bill due to non-disclosure agreements, built an application to calculate the credit worthiness of Government Contracting Firms. In short, it uses financial data and a custom algorithm to give a ranking based upon those of similar business.
For years the system has worked fine. Making it easy to qualify contractors for bidding on large projects. However, during an application update, the code was audited to reveal multiple issues. The questions became leave well enough alone or improve the code.
The big questions being, “Why spend time and money on correcting a working system?” The answer is the same one your mechanic asks when working on your car. It is to ensure that it continues to work at the highest level possible. You fix the car to ensure it will not leave you on the side of the road. You audit the code to ensure your business is not left behind due to embarrassing future problems.
As someone who has managed over 100 software projects I equate the code audit to an x-ray. While a broken arm or finger may appear to function properly on the surface. There is a break that must be healed for it to gain full movement and strength.
However, unlike bones, software does not heal itself. Therefore, it is best to go ahead and rework the code so that it functions better. Over my 22 year career as a Software Engineer and later Engineering Manager, I have not seen an application with anything close to perfect code. Including all of the software that is relied upon daily by most of the Internet.
During the code audit, a person and/or application reads over each line of code and compares it to a specific standard. This may include a language standard or company requirements. Particular attention is made to such things as proper naming of variables, scope, dependency injection, etc.
Any code not meeting the standard is recorded by file and line number for later review by a developer. At the same time, attention is paid to duplicate functionality, logic errors, proper handing of exceptions, and numerous other items important to the application.
The end result of the audit is a document that outlines all areas of concern with a ranking of risk. For example, a Boolean Variable named “notOK” may be low risk. However, since the negation makes logic confusing, its risk may be higher. Regardless, a note to change it to “isOK” with a change to the associated logic will be noted.
One of the most common occurrences is duplication of concern. For example, there may be no two methods that are exactly the same, but there is often one or more methods that do roughly the same thing.
For instance, consider a “SendEmail” and a “SendSMS” method. Both send messages but do so using separate protocols. Instead of including two methods, they may be combined into one called “SendMessage” with a message type parameter to determine if its an Email, SMS, or some future type.
In contrast, doing so may be cause the code to be more confusing. This is the a core benefit to the audit as it opens up questions and forces the development team to defend their decisions. Forcing the developer(s) to revisit their thought process. Usually much better the second time around than the first due to not having the pressure to finish.
In a more sophisticated code audit, the logic and calculations are tested with formal proofs. The reason is that is near impossible to test code for every state that could occur. Instead, we prove if it will work across all states using mathematical proofs.
The reason for this is to ensure a future, yet to be realized, state does not render the software useless as was the case with a Hedge Fund client and their Arbitrage Strategy System. Once the proofs match the code, the system is deemed accurately robust.
In closing, it is better to break your prized work under controlled conditions to have it break on its own in the wild.
While reading this, you have probably though of a person or network. If so, please share it with them. When you are ready to learn more about delivering neatly defect code fast, visit https://toddmoses.com.
