The acronym of COBOL stands for (Common Business-Oriented Language). A imperative, procedural and English-like programming language designed by Grace Hopper In the sixties.
COBOL has the reputation of being totally outdated, even most universities don’t teach COBOL these days. COBOL is commonly used on mainframes, especially in industries such as banking, aviation, insurance, government, healthcare, and automotive. In this article, we explore the reasons for the continued use of COBOL and mainframes, and the problems this poses for an industry that relies on a more than 60-year-old programming language to process $3 trillion in transactions every day.

The Relevance of COBOL and Mainframes

According to surveys by Micro Focus (2022), around 800 billion lines of COBOL code are used in production every day. 50 percent of the companies surveyed believe that they will be using more COBOL code in 12 months’ time than they currently do. 92 percent of respondents stated that their organizations’ COBOL applications are strategic with future IT strategy. Between 60% and 80% of all transactions conducted worldwide are done in COBOL.

During the Corona crisis, COBOL even made headlines when the U.S. government had problems with its COBOL-based IT, when suddenly 10 million people were out of work, and retired engineers came to the rescue.

Why Companies Stick with the Old

1. Stability and Reliability: COBOL and mainframes have proven themselves over decades, providing the stability that is critical for systems that handle essential business operations. The reliability of these systems outweighs the perceived benefits of adopting newer technologies.
2. Legacy Code Dependence: Many organizations have vast amounts of legacy COBOL code, often developed over years or even decades. Rewriting or replacing this code is a daunting task that carries significant risk and cost.
3. Mission-Critical Systems: COBOL underpins applications that are critical to business operations. The potential disruptions and financial risks associated with migrating away from these systems make organizations hesitate to make the transition.

Industry Challenges and Costs

The industry faces several challenges due to the continued use of COBOL and mainframes.

One pressing issue is the shortage of skilled COBOL developers. As the demand for COBOL engineers continues and the so-called “COBOL Cowboys" age out of the workforce, companies are struggling to find qualified professionals, resulting in a competitive job market. To be fair, due to the enormous code base that exists in the companies, the day-to-day work consists more of fixing bugs than developing new innovative solutions. Maintenance isn’t everyone’s idea of an exciting job, but maybe it is for some of us.

In addition, mainframes are generally expensive to maintain and to upgrade. IBM’s monopoly position in the mainframe market adds to the financial burden on businesses, limiting options and potentially stifling innovation.

Despite the good reasons for sticking with COBOL mentioned above, for some companies the negatives outweigh the benefits and they have managed to migrate their technology stack.

Migration Stories

Several companies have successfully moved away from COBOL and mainframes and adopted newer technologies to future-proof their operations. For example, Capital One moved from mainframes to microservices and cloud-based solutions. Their success can be attributed to careful planning, phased implementation, and a commitment to addressing the challenges posed by legacy systems.

Why It’s Hard for Others

1. Complexity of Legacy Code: As mentioned above, the sheer volume of existing COBOL code is a daunting challenge. For many organizations, the complexity of deciphering and rewriting this code is a major deterrent.
2. Fear of Service Interruptions: Organizations fear that migrating away from COBOL and mainframes will result in service disruptions that will impact operations and potentially cause financial losses or even bankruptcy.
3. Regulatory Compliance: In highly regulated industries such as finance and healthcare, compliance concerns make it difficult to make the transition. The long-standing presence of COBOL has made it easier to comply with regulations, making organizations reluctant to change.

Conclusion

The lack of qualified developers, the high maintenance costs and IBM’s monopoly do not make the situation easy. Some successful migrations show what is possible with precise planning. Despite the age, COBOL and the mainframe will survive due to their stability, reliability, and the challenges associated with migration, and as we have seen, the market is actually growing. It remains to be seen which path the industry will take. Currently, the developments in generative AI are a promising solution to solve the lack of developers in this area, but it remains exciting — maybe one day I will give my kids some COBOL lessons ;).

PS: Funny… today I found out that Cobol was part of my university script, namely the implementation of the Fibonacci sequence: https://github.com/KnowledgePending/COBOL-Fibonacci-Sequence/blob/master/fib.cbl

In the dynamic realm of software development, the pursuit of perfection often walks hand in hand with the need for effective decision-making. However, the pitfalls of overthinking can cast a shadow on the development process, leading to delays, missed opportunities, and the unintended costs of implicit decisions. In this article, we’ll explore the delicate balance between perfectionism and decision-making in software projects.

The Perfectionism Paradox

The desire to create flawless code and excellent solutions can unintentional lead to excessiv analysis and lenghty decision-making processes (Analysis paralysis). It is important to recognize the fine line between the pursuit of excellence and the danger of perfectionism.

The Cost of Overthinking

In software development, time is of the essence. Overthinking often leads to a state where teams are so focused by the desire for a perfect solution that decision-making comes to a standstill. The cost of overthinking is not merely the time lost in indecision: it extends to missed opportunities, strained team dynamics, and the unintended consequences of implicit decisions made under pressure.

Implicit Decisions and Their Hidden Costs

Implicit decisions, often born out of indecision or rushed choices, can have far-reaching consequences. A seemingly harmless assumption made early in the project can lead to a lack of flexibility, requiring extensive refactoring down the line. Understanding the hidden costs of implicit decisions is crucial for fostering a culture of conscious decision-making.

Embracing Iteration and Learning

The Agile methodology, with its emphasis on flexibility and responsiveness, provides an effective antidote to the pitfalls of perfectionism. Instead of striving for perfection from the outset, embrace an iterative approach. Make decisions based on the best information available, knowing that adjustments and improvements can be made as the project progresses. This requires an environment in which decisions can be reflected upon.

Start Documenting Decisions

If the team does not record decisions, how do you want to reflect on them interactively, especially if the team composition changes?
Tools like Architecture Decision Record (ADRs) are a good way to document decisions and consequences of each choice.
Start with a document on a place where your whole team can collaborate together. There are plenty of templates for ADRs. Keep them short one or two Pages max. Large documents are never kept up to date.

Keep Learning and Iterate

Embrace a learning mindset. Treat each decision as an opportunity for growth, learning from both successes and failures to continually refine the decision-making process. If a decision leads to unexpected challenges or inefficiencies, a continuous learning approach encourages the team to analyze the situation, learn from mistakes, and make informed adjustments. If you have an ADR and the decision is reversed keep the old one around and mark it as superseded. It could be relevant to know what was the decision once, but is no longer the decision.

Conclusion

In an environment as dynamic as software development, perfectionism can hinder progress and stifle innovation. Striking a balance between the pursuit of excellence, the costs of delayed decisions, and the need for timely decision-making is crucial for success. By embracing an iterative mindset, implementing decision frameworks, and leveraging Agile methodologies, software development teams can navigate the perfectionism paradox, avoid the hidden costs of delayed decisions, and deliver outstanding results in a rapidly changing landscape.

Remember that the perfect is constantly changing. It is a constantly moving target that will never stop.

Reference:
Decision record templates: https://github.com/joelparkerhenderson/architecture-decision-record