Handling Technical Debt
Like monetary debt. It will piles up, grows and accumulates ‘interest’ in the process.
“So that’s how we should’ve done it” might be a typical moment of realisation after spending some time in developing software. In Software Engineering discipline, this is dubbed as “Technical Debt”. You get technical debt when you don’t design things carefully. For example: unintelligible variable names, inefficient algorithms, poor division of modules.
It works just like monetary debt; the more you ignore, the more it piles up. Plus, it gets more difficult when one particular problems are left for a long time; nobody remembers why they made it that way.
Dilemma #1: We don’t have time for design!
Practically, Technical debts is a consequences of using any ‘easier methods’ instead of using best practices which takes a longer time. This may cause additional rework and revisit. Common rule of thumb is that reworking will take a longer time compared to careful planning. However, responding pressure from business, this is hard to be done, especially in a larger team.
This case is primarily a proponent to the Agile Methodology: a method which divides development into smaller chunk (called sprints). But there’s a catch: Agile methodology also did not excuse ‘bad code’. So, No — we should make time for a design. After months of iterations, usually bad code piles up and it gets worse in Agile methodology. Bad codes usually leads to hard-to-solve-bugs in later implementations.
In a larger team, a discipline in convention is needed. This would reduce the amount of work needed to refactor bad codes. Here’s a practical article explaining about code conventions Don’t Repeat Yourself (DRY) and Single Responsibility Principle (SRP). You will need to maintain the discipline by holding periodic code review 1 full-day just after release week.
There’s a rule of thumb: 1 function logic usually created within 10 lines of code. For example, don’t mix up functions to fetch data with the one to parse and summarise it. One way to do it is to push all parsing and summarising logic to the database query. In general there are 3 types of functions: fetch/save, processing and display. All these category of functions should not overlap one-to-another.
Dilemma #2: Over Engineering Pitfall
This is the opposite of what happened at #1. Now that you think you need to make sure everything okay, and you anticipated for an enterprise expansion in next few years, you created a Fintech that does not only let you buy investment products; there’s also discount scenario, referral promo and point system that was not requested by users.
There’s a popular term called You aren’t going to need it (YAGNI) as stated by Founder of Xtreme Programming methodology, “only 10% of the features you build will be needed by the users”. The rule of thumb are that the only way you can anticipate for functional expansion is to make your app as stupid as possible — the thought was the origin of Minimum Viable Product (MVP). Because 90% of the feature that your user needs are only verified once you understand their behaviour. Be ready to pivot your business, market segments and the product offering all at once.
Don’t forget that over engineering may lead not only to complexity of the code. It would also overwhelm most typical users and potentially reduce the usability.
