Debugging Finances through Code Practices

What'sbad code? We can have a generalized answer i.e. “the code which doesn’t fulfill its intended purpose”. And the reason for such a failure can range from working on an old code with a specific extension attached with it to the developer, who uses an easy way to get the code completely with shortcuts.

There isn't any specific answer to this one and sometimes many, but for me who came across it for the first time as I joined Lights Out which has a large portion of its operations in design and development I had to get familiar with it fast. After a while I understood that getting a grasp of what defines a code; deliverable will be too deep for me to get ahold of while also streamlining the finances of the company as a whole.

So I started to look at it in a financial term as it will help me to relate to it. So I came acrossTechnical debtbut now, What is technical debt? It is an estimated cost of future development to make the code optimally maintainable again. Technical debt does not apply just to code, but to the overall system and its architecture.

If technical debt means, future cost to convert such code into an operational one, then the cost incurred till this point would give me the cost of a bad code. So I related it to two costs found in almost every financial statement are -

1. Sunk Cost which means cost which is already incurred and is unrecoverable.
2. Phantom Cost which means cost which is not regular or ordinary business expense.

The commonality between these two and bad code was that like Sunk cost, the cost of a bad code is historical in nature as it's hidden till the code's tested and verified and is irrecoverable.

D2C’s have a long-practiced ability to meet these challenges. As Nik mentions in our conversation, the foundations of a good D2C brand are its

• content messaging (think about the emails and newsletters you’re getting from your brands)
• the community around its product
• personalisation of product fulfilment.

The pandemic burned every physical bridge between the consumer and brand. This did not seem to disturb D2C brands, whose fundamental business practices involve their customers in ways that have not depended on these physicalities, and in a manner that must anyway call for being regularly communicative in its content.

Like Phantom cost, a bad code would not be regular or ordinary to the business process in nature to pinpoint any specific deficiency causing such cost.

So once we have converted the problem in the terms of the solution we need to move forward with the next part of the solution, SoPs.

SoPs (Standard Operating Procedure) helps in creating a solid base for an action plan to avoid technical debt or accumulation of it. Being aware of the possibilities of the technical debt helps in mitigating the risk and cost of a bad code as it does not take the whole project down with the surprise of it. 

Just like the way to tackle Sunk cost, the cost of a bad code has to be anticipated through risk analysis and included in the margins of its project with materiality in mind depending upon the probability of it occurring in relation to complexity of such deliverable. So to not be in a situation where the project becomes a liability in both contractual and financial terms. 

And like Phantom Cost has to be made a note of and be prepared in future situations to get the course of action needed from such past instances. 

How SoPs help lower the risk of technical debt -

• Overall Risk analysis of the Project.
• List of areas from the scope/deliverables of the project which are most prone to code risk. (Code Risk is the probability of code going bad).
• Clarity regarding the scope, deliverables and the acceptance level of such deliverables with both the clients and collaborators. The best response is to always be honest about the situation and to give a true and fair idea of the problem which has come up with possible solutions.
• Regular modifications to the risk portfolio through the project span.
• The type of refactoring which might be needed as per the Risk analysis.
• Re-course plan in case of no-return point.
• Close the technical debt and document the reason for it.

In cases where the technical debt goes unchecked it can cause the whole project to go down and may be a cause for a lawsuit which could threaten the going concern capability of the organization as a whole. So it’s always advisable to have an E&O (Error and Omission) liability insurance.

An E&O (Error and Omission) liability insurance provides cover to companies and professionals against claims of inadequate work or negligent actions made by clients and helps the company avoid a substantial financial hit—even bankruptcy—depending on the company's finances.

Depending on the finances and work procedure of an organization. An organization should look at D&O (Directors and Officers) insurance cover, it is liability insurance payable to the directors and officers of a company, or to the organization(s) itself, as indemnification for losses or advancement of defense costs in the event an insured suffers such a loss as a result of a legal action brought for alleged wrongful acts in their capacity as directors and officers. This helps in safeguarding the organization and other concerned parties from a lawsuit due to the action which they were not privy/in consent of. 

In conclusion - 

As a prudent businessman needs to be agile to know the bottleneck, similarly anticipating a bad code is the best way to avoid it. 

Being aware of Technical debt and communicating the same to each party connected to the project, has to be done. Risk analysis of the project and finding the area of scope of work which is most prone to risk is important and updating the same during the project life span while keeping the refactoring/re-course action ready in case anything goes south.