Y2K bug : is it just a bug or made of technical debt?

Credit: DALL-E

Have you guys ever heard of the Y2K bug? it was something that shook the whole world. Year 2000 (Y2K) was a computer error dubbed the “Millennium Bug” that caused concern and fear in the year 2000. When the program was first created in the 1960s for a complex computer, the engineer represented the year with his two-digit code, omitting the “19”. Many believed that as the year 2000 approached, the system would not interpret “00” correctly, causing great confusion in the system.

The Y2K bug triggered a worldwide panic, affecting many countries such as France, Japan, and Indonesia. In France, the weather map system encountered issues, displaying 19100 instead of the accurate year as the new millennium began. Bank Indonesia’s display system also misinterpreted the year change, reading 1900 instead of 2000. Japan faced problems with power plants when connecting computer systems to radiation monitors, impacting the operation of PLTN.

The Y2K bug stemmed from a programming convention aimed at conserving memory and storage space. Many computer software systems, including the Basic Internal Operating System (BIOS), Operating Systems (OS), and Application Software, abbreviated the year to two digits, using the format DD/MM/YY. However, the convention became problematic during the transition from 1999 to 2000 when the two digits representing the year 2000 were interpreted as “00”. Many older systems built in the 1960s to 1980s used this convention. For example, clocks in microprocessors and software registered the year 1999 as “99”, assuming “19” would follow, which resulted in ambiguity and incorrect calculations. People worldwide often claim that a bug was responsible for the technological catastrophe, and a plethora of unfounded theories have emerged on the topic. Initially, the prevailing belief was that it constituted a bug; however, it was, in fact, a manifestation of accumulated tech debt. The prevailing narrative surrounding the Y2K event has given rise to misconceptions and the proliferation of misleading theories. Many individuals mistakenly attribute the resulting disruptions to a bug, whereas the reality is that it stemmed from unresolved tech debt.

Credit: DALL-E

Tech debt or technical debt is the ‘debt’ that arises when developers prioritize releasing a largely functional project over perfecting the coding process that will affect them in the future. Accumulating tech debt requires refactoring or restructuring code without disrupting the main function, and the longer it persists, the more costly it becomes to rectify. The main goal of software development at that time was to fulfill functional requirements, perform desired operations, and complete the project within the set time limit. The presence of tech debt that led to the Y2K bug was a result of decisions taken at the time without considering the impact that would occur when the year 2000 arrived.

The Y2K bug provides valuable insights into tech debt management. While tech debt is often viewed negatively, it can have positive impacts if managed effectively from the beginning of a project. In the case of the Y2K bug, intentionally incurring tech debt initially helped reduce memory usage and enhance program speed. However, the lack of prepared solutions to address the tech debt led to the bug. Similar to financial debt, tech debt must be accompanied by good risk management to prevent it from becoming burdensome in the future.

Aside from the Y2K bug, several actions in application development can result in tech debt. One such occurrence is the lack of documentation, which may seem trivial but can lead to significant tech debt during application maintenance, especially when original programmers are no longer part of the team. Both the Product Team and the development team can engage in actions that generate tech debt. For example, creating multiple methods with the same functionality can make the application complex and difficult to troubleshoot, resulting in the accumulation of more tech debt.

In addition to the y2k bug case we discussed earlier, numerous actions in application development can lead to tech debt. These actions can be categorized into two types, Common Tech Debt in Product Team and Common Tech Development Team.

Common Tech Debt in Product Team (Managing) example :

• Lack of Documentation: Insufficient or outdated documentation can create challenges when onboarding new team members, understanding the system’s architecture, and ensuring long-term maintenance of the product.
• Unresolved bugs and issues: Prioritizing new features over fixing bugs can result in accumulating technical debt if critical issues are left unresolved, leading to decreased product quality and customer satisfaction.
• Inconsistent development processes: When each team member follows different development processes, it can cause inefficiencies in project management, code integration, testing, and implementation. Inconsistent development processes require more time and resources to complete tasks, leading to an increase in tech debt.
• Ignoring good architecture: Building an application without considering sound architectural principles, such as layer separation or modular design, can result in complex and difficult-to-change code. When changes are required, modifying a specific part of the code can impact many other parts, increasing tech debt.
• Backlog accumulation: Poorly managed backlog, with delayed features or unprioritized customer requests, can lead to the accumulation of tech debt. This hampers the team’s ability to deliver new features quickly and efficiently.

Common Tech Development Team (Code) example :

• Code duplication: Having multiple code duplications with the same functionality can make maintenance difficult and increase tech debt due to the challenges in tracking the code.
• Lack of error handling: Insufficient error handling in our code can result in future tech debt as it becomes challenging to debug and identify issues.
• Lack of code standardization: Without proper code standards in place for application development, each individual will have their own coding style, making it challenging when it comes to future redevelopment.
• Neglecting security concerns: A good application should prioritize security. However, often we prioritize functionality over the security aspects of our application, which can lead to significant tech debt in the future.
• Unupdated frameworks or dependencies: Using outdated frameworks or dependencies that are no longer actively maintained can result in security vulnerabilities, performance issues, or unfixable errors. Updating or replacing obsolete dependencies will require extra effort, and if ignored, it will increase tech debt.

The Y2K bug serves as a compelling case that underscores the importance of addressing tech debt to avoid potentially serious consequences. Initially, tech debt may serve as a quick solution for development teams when confronted with challenges. It may be necessary to overcome other obstacles and expedite the development process. However, if not managed with a well-defined strategy, tech debt can have detrimental effects on sustainable products over time. It can lead to decreased performance and potentially give rise to issues like the notorious Y2K bug.

Ultimately, we cannot entirely prevent or eliminate tech debt; it inevitably accompanies us throughout the lifespan of any project we undertake. However, it is imperative to seek solutions as promptly as possible whenever tech debt emerges. This proactive approach is crucial because the longer we allow tech debt to persist, the more time and resources will be squandered in addressing it in the future.