Featured Image

May 21, 2020

Education is vital to legacy applications’ future – podcast

May 21, 2020

By Todd Erickson

Educating young developers about the importance of legacy software applications, and building the tools needed to connect them with modern technologies are the keys to combining old-school reliability and new-school engineering say Bill and Eileen Hinshaw of COBOL Cowboys.

If you've followed the stories about the computer-system meltdowns brought about by the overwhelming demand for government financial assistance during the COVID-19 pandemic, then you've probably read about COBOL Cowboys.

The Hinshaw's founded the company to bring together experienced programmers and organizations that lack the expertise needed to fix and maintain their legacy applications.

When the system failures started, government officials were quick to blame their back-end mainframe applications, just as they did during the Y2K crisis. However, those same officials were forced to backtrack when Bill and others revealed that the mainframe applications were fine – it was the agency's infrastructure and front-end systems that caused the problems.

Bill and Eileen have done a number of interviews about the system failures, but now they want to talk about moving forward to ensure that these legacy systems are updated using modern technologies, so they don't get blamed for the next computer catastrophe.

That's where education and better tools come into play. Bill and Eileen say the good that's come from our current situation has been the increased public and industry awareness of how important legacy systems are to industries and companies around the world.

Their goal is to educate young software developers on the advantages of mainframe systems so more programmers will be interested in working with them and will replenish the declining workforce.

Learn more about the COBOL Cowboys and how critical mainframe applications are to the world in this Phase Change podcast.

Todd Erickson is a Technology Writer at Phase Change Software. You can reach him at [email protected].

Published by Phase Change Staff in Technology
Tags: audio, bill hinshaw, cobol, cobol applications, cobol cowboys, eileen hinshaw, interview, legacy systems, maintaining legacy systems, modernization, podcast
Featured Image

April 1, 2020

IRS stimulus-check delivery faces knowledge gap challenges

April 1, 2020

by Steve Brothers

reuters article march 22 2020 on why stimulus checks could take months to deliver

© 2020 Thomson Reuters

A Reuters' article published March 22, 2020, claims that the IRS will have difficulty delivering stimulus checks to help Americans endure the economic hardships caused by the mandated social-distancing protocols put in place to combat the COVID-19 global pandemic. The story, written by Washington, D. C., correspondent Andy Sullivan, explains how budget cuts and reliance on obsolete technologies, including COBOL-based applications, may not only delay the delivery of the stimulus checks by months but are also preventing the agency from effectively completing its main job of collecting tax revenue.

While the article incorrectly judges the usefulness of COBOL because the IRS can't find enough qualified programmers, it does highlight the issue that Phase Change has been pounding the table about for years – the lack of qualified legacy application developers is a major problem for the enterprises and government bodies that rely on them.

COBOL-based applications quietly run in the background conducting a large share of the world's financial, healthcare, and government-agency business, including the billions of ATM transactions that occur every day.

A great number of the developers that maintain COBOL-based applications are retiring, and the younger generations of programmers don't have much interest in learning the language. More importantly, the application knowledge lost when experienced developers walk out the door cannot be easily replaced by reliant organizations such as the IRS.

The programmers the IRS adds to support the $2 trillion economic stimulus package will not be ready to support the agency's massive delivery of stimulus checks. They may be experienced developers, and they may have a good grasp of COBOL, but they do not understand the complex applications the IRS uses to process and issue recovery payments.

If you think the tax code is complicated, consider that in 2018, the IRS codebase contained an estimated 20 million lines of code that encapsulates nearly 60 years of legislative and system changes.

It can take months for programmers to become productive in applications new to them, and possibly years to become proficient. During the time they are learning the source code, they are more likely to make mistakes and definitely require mentoring and oversight, which decreases the productivity of the rest of the team, prolongs the time it takes to complete projects (such as mailing checks) and increases the risk of major mistakes.

That knowledge gap is what the IRS and many other organizations reliant on COBOL applications are facing today.

Steve Brothers is the President of Phase Change Software. You can reach him on LinkedIn or at [email protected].

Published by Phase Change Staff in Applied
Tags: cobol, cobol brain drain, developers, legacy systems, software development, system knowledge
Featured Image

December 11, 2019

How short-term maintenance practices can double application size in 5 years

December 11, 2019

by Todd Erickson and Elizabeth Richards

Software must evolve to stay effective, which makes application maintenance a persistent and growing obligation, especially for organizations with large, legacy systems.
Changing marketplaces, compliance updates, security patches, hardware improvements, bug fixes, and process updates all drive code changes.

In his book, Building Maintainable Software: Ten Guidelines for Future-Proof Code, Software Improvement Group Co-founder and CTO Tobias Kuipers says that in larger codebases, 15% of the source code is changed each year.

And software maintenance isn't cheap. Kuipers says that some of his clients spend up to 90% of their IT budgets on program upkeep.

A common problem is the technical debt that piles up when the software team doesn't understand the code they are modifying and its system interdependencies. Combine that lack of knowledge with time and resource demands and the team often resorts to short-sighted modification techniques that add code instead of modifying it in place, which only increases the codebase size, complexity, and technical debt.

Maintenance Challenges for Legacy Code

Legacy applications can have massive and complex code bases created by hundreds of developers throughout decades of work. For example, in 2012, The Bank of New York Mellon reported that its core banking system contained 323 million lines of code and 112,500 COBOL programs. With that size and complexity, even an experienced developer can’t know the whole system.

One issue is the lack of useful documentation. A Catholic University of Brazil study found that between 40% to 60% of maintenance activity is studying the software just to understand it, and the impact analysis required to make the changes without breaking functionality.

Updating documentation can shorten time-to-competency, but it's frequently a low-priority task when stakeholders are demanding that bug fixes, security updates, and functionality improvements be completed yesterday.

Another challenge is institutional brain drain. Inevitably, experienced developers depart the software team, and the loss of that expert knowledge extends the amount of time it takes new developers to understand the applications because there are fewer experienced colleagues they can rely on for assistance.

How do software teams cope?

Application change is required but the lack of understanding introduces risk. To decrease immediate costs and risks, developers and managers may choose to use short-sighted strategies.

Don’t touch the black box

One technique programmers use to avoid breaking unmanageable applications is building separate subsystems (Figure 1).


Just copy the whole damn thing

Another tactic is to duplicate the applicable code (Figure 2). Good development practices recommend editing code rather than duplicating it, but if developers don't understand the code they are editing or its interdependencies, they risk breaking the old functionality.

Instead, developers leave the applicable code in the application, but copy it and place the copy in a new location. Then they modify the duplicate code, hopeful that by leaving the original code in place, they won’t break its functionality.


Duplicating code reduces the risk of breaking the application in the short-term but increases maintenance costs and program complexity in the future. By adding 15% to the code base annually, it will double in just 5 years, making maintenance that much more difficult, expensive, and risky.


Conclusion

Companies face a difficult situation when they choose short-terms strategies that avoid immediate cost and risk but end up creating long-term technical debt.

The solution is to ensure that developers understand the code completely to make sound development decisions. However, the speed of business and technical change affords few organizations the time needed to completely understand their applications.

To learn more about how Phase Change's COBOL Colleague helps developers understand complex COBOL-based applications and make changes quickly and confidently, visit Phase Change's product page.

Elizabeth Richards is Phase Change's Director of Business Operations. You can reach her at [email protected].
Todd Erickson is a Technology Writer with Phase Change. You can reach him at [email protected].

Published by Phase Change Staff in Applied
Tags: application comprehension, application maintenance, black box, brain drain, change impact, comprehension, legacy systems, software development, technical debt, understanding, understanding code
Featured Image

April 24, 2019

The cost of fixing COBOL bugs

COBOL maintenance costs are rising as aging developers leave the workforce and well-trained replacements are in short supply. Learn about how pervasive COBOL-based applications remain, why the supporting developer workforce is shrinking every year, and scrutinize our estimates of how high these applications' maintenance costs are rising.

I began working with mainframe programming languages in 1990 while I was in college. I started with FORTRAN and assembly languages, and I knew about COBOL but wasn’t exposed to it until much later.

While FORTRAN and assembly languages now have their niche uses, COBOL is entrenched as a vital part of the global economy. And now the cost of maintaining the nearly 60-year-old language is rising precipitously.

A little history

The Common Business Oriented Language (COBOL) was developed as a stop-gap measure during the second Eisenhower administration to create a portable mainframe programming language for the Department of Defense. It was based on the FLOW-MATIC compiler, which was recognized as the first English language data-processor compiler and was designed by Rear Adm. Grace Hopper.

I predict that the last mainframe will be unplugged on March 15, 1996.
~Stewart Alsop II, InfoWorld magazine, 1991

The bad news is that some of these applications are nearing 50 years in age. And although COBOL remains vital to many critical systems, this prominence has not resulted in a stable supporting workforce. The population of experienced COBOL developers declines at least 5% every year because of retirement. The population’s average age is roughly 55 years old, and the language’s absolute uncoolness has motivated the majority of university computer science programs to drop their COBOL classes entirely. The trickle of newly trained COBOL programmers are coming from community colleges, technical schools, and programs run by private companies such as IBM.

The continuing importance of COBOL-based applications and the diminishing trained workforce is causing the cost of maintaining COBOL-based applications to rise.

How often do defects arise?

You might ask, “Well, if COBOL is so reliable, why do we need lots of programmers? Fewer bugs naturally means fewer engineers.”

That sound perfectly logical, however, in my experience, due to the lack of a sufficient supporting workforce and the spaghettified nature of today’s COBOL-based applications, they are not modified and supported as well as other applications programmed in more popular languages.

Think about all the patches, additions, and technical debt that have built-up since these applications began surfacing in 1960, as well how many developers contributed to those applications but are no longer around to address issues and answer questions.

Due to the uncertainty of downstream impact and to reduce the risk of breaking critical applications, I believe many COBOL engineers duplicate hundreds or thousands of lines-of-code when making changes or repairs because they do not completely comprehend the COBOL code in their system. As a result, changes are made, tested, and implemented in an environment of uncertainty and heightened risk.

And when the flaw is discovered, the repair cost includes:

  • Consultants or outside IT contractors
  • The development team’s time away from building new features and products
  • Salaries of internal personnel tasked with fixing the bug or supporting the project
  • Application downtime
  • Lost business opportunities

The Y2K scare is just one example. While it ended up being much less daunting than many estimates, roughly $320 billion was spent worldwide evaluating and fixing systems.

But the price of fixing COBOL code includes more than just repairs and downtime. An organization’s security, reputation and market position can be affected by one time-bomb defect. When an August 1, 2012, software failure caused Knight Capital LLC to create thousands of trades per second on the New York Stock Exchange, the company lost between $440-460 million in 45 minutes. By the next day, Knight’s stock had fallen 75% and within the year the company was acquired by a rival.

What is the cost of fixing COBOL code?

So, what is the actual cost of fixing COBOL code?

For the sake of simplicity, let's analyze the cost based on salaries and time spent supporting COBOL-based applications, but not developing new programs.

Here are our assumptions:

If we conservatively estimate the cost of maintaining COBOL-based applications by only including the developers working solely on maintenance, it’s roughly $1.02 billion per year. Here’s how we get there.

20,000 COBOL developers
x 42% solely doing maintenance
x $81,000 per year                           
= $680.4 million per year

In my experience, you have to add another 50% of the development cost for quality assurance (QA) testing, which would bring the total to $1.02 billion just in the U.S.

$680.4 million
+ $340.2 million for QA testing     
= $1.02 billion per year

If anything, these numbers are low because we didn’t consider the companies doing both maintenance and new development in COBOL.

The cost of fixing COBOL v. alternatives

Another approach to handling applications written in legacy programming languages is to modernize the code – translate the COBOL source code to a modern language such as Java.

Despite the astronomical maintenance costs, it doesn’t necessarily make sense to modernize COBOL-based applications. Hundreds of millions of dollars are spent each year on COBOL transformation projects, and more than a few have ultimately failed.

The risks associated with a COBOL transformation project are significant. Dave Brown, Systems Architect at The Bank of New York Mellon, said in 2012 that his bank had 343 million lines of COBOL code. Transforming a code base of that size and complexity would take years and hundreds of millions of dollars.

Just ask the executives at the Commonwealth Bank of Australia, which undertook a planned AU $580 million (US $413 million) legacy core banking technology transformation in April 2008. The project was finally completed in August 2013 at a final cost of AU $1.1 billion (US $783.871 million) – almost two years behind schedule and $370 million over budget. And this was a successful legacy system conversion.

The COBOL programming language is not destined for retirement. Organizations can plan on continuing to spend a high percentage of their IT budgets maintaining legacy systems, especially in the financial and government sectors. An April 2017 article by NextGov.com claims that the federal government spent roughly $90 billion in 2017 maintaining legacy systems, which was roughly 80% of its entire IT budget ($90 billion in 2017).

Until new technology comes along to enable organizations to better understand their COBOL-based applications, unravel their complex and spaghettified code, and extract the embedded technical, business, and regulatory knowledge buried within, this trend will continue. Whichever approach you take, right now the only solution is to throw time and money at the problem.

Published by Phase Change Staff in Applied
Tags: break-fix, cobol, executives, greg brueggeman, legacy code, legacy systems, mainframes, maintaining legacy code, maintaining legacy systems
Featured Image

February 11, 2019

Phase Change CEO Steve Bucuvalas featured on the InfluenceNow! podcast

February 7, 2019

by Todd Erickson1

Phase Change’s Inventor, Founder, and CEO, Steve Bucuvalas, was featured in the January 31, 2019, episode of the InfluenceNow! podcast, hosted by Justin Craft2.

The InfluenceNow! podcast highlights startups, exceptional business influencers, and ideas from a variety of industries that influence the world.

Steve and Justin discussed how Phase Change and the technology behind Mia, the first cognitive agent for software development, became a reality.

The interview begins with Steve describing his career leading technology and artificial intelligence (AI) groups in financial services and insurance companies, and his subsequent entrepreneurial career starting and selling two different companies. He tells the story of how a single conversation with the buyer of his second company led to his interest in applying AI technology to the problem of software-development productivity.

At the closing, the buyer said to me, 'What's wrong with you guys in software? AI has changed financial services extraordinarily - increased our productivity 100 times,' which is accurate. 'Why can’t you do that with your own industry?'

That moment led Steve to research the barriers to applying AI to software development, and the development of the human-centric principles that led to the creation of the Mia cognitive agent.

The podcast continues with Steve and Justin discussing why organizations that rely on applications written in the Common Business-oriented Language (COBOL) programming language are Phase Change’s first target market.

COBOL is this 40-50 year-old language that has atrocious legacy problems. Because the code has been around [so long], it runs 85% of the world’s financial transactions and [there’s] 220 billion lines of [active COBOL] code. The programmers are all in their 60’s and they all want to retire, but they keep getting incentives to work a few more years because no one wants to learn COBOL. In fact, some of the kids in computer science [college courses] have never heard of it.

Justin and Steve conclude the interview discussing the productivity gains realized by Mia and Phase Change’s technology, and when it will be generally available.

To learn more about how Steve and Phase Change Software will radically improve software productivity, watch the podcast video below or listen to the audio podcast.


1Todd Erickson is a tech writer with Phase Change Software. You can reach him at [email protected].
2Justin Craft is the Founder and CEO of Cast Influence, a Denver, Colorado,-based turnkey marketing agency. Phase Change Software is a client of Cast Influence.

Published by Phase Change Staff in Applied, Company, Technology
Tags: artificial intelligence, cobol, industry turnover, influencenow, interview, legacy systems, mia, podcast, productivity, software development, steve bucuvalas
Featured Image

December 19, 2018

Phase Change unveils COBOL Colleague product website

December 18, 2018

by Todd Erickson

Phase Change announces the launch of its initial product website – CodeCatalyst.ai. The website will support the company's market entry product, COBOL Colleague, the first cognitive tool for software development, by targeting organizations that rely on COBOL-based applications for critical business operations.

The CodeCatalyst.ai website details how COBOL Colleague will assist COBOL reliant organizations with their unique issues, such as a vanishing workforce, lost application knowledge, and lagging productivity.

COBOL Colleague reads-in the source code, extracts the embedded concepts, discovers the dependencies, reveals the buried knowledge, and becomes an expert that never tires and never leaves.

Natural-language-interaction enables developers and stakeholders with limited COBOL experience to collaborate with the cognitive agent and work productively with their COBOL applications.

Find bugs and dead code in seconds, not minutes or hours. Make changes with full knowledge of the downstream impact. Confidently add new features, products, and services. Empower anyone with a basic understanding of COBOL to interact and engage with your COBOL applications.

Everything you dreamed of in COBOL-based environments is now a reality. Visit CodeCatalyst.ai.

Todd Erickson is a tech writer with Phase Change Software. You can reach him at [email protected].

Published by Phase Change Staff in Company
Tags: cobol, cobol brain drain, cognitive agent, industry turnover, legacy systems, natural language, productivity, project team, software development, todd erickson, understanding
Featured Image

October 30, 2018

COBOL is dead! Long live COBOL!
A living collection of COBOL articles

updated March 16, 2021

by Todd Erickson

To stay up-to-date with the latest news and commentary surrounding COBOL-based applications, we track and archive COBOL-related online articles. Below is our current collection of stories, which we try to update frequently.

Despite its age and multiple reports of its impended death, the Common Business Oriented Language (COBOL) remains responsible for a large portion of the world’s daily financial transactions – credible estimates include as much as $3 trillion per day and roughly 90 percent of all ATM and in-person financial transactions.

COBOL was first published in January 1960 by the Conference on Data Systems Languages (CODASLY), who based it on the first compiler developed by Admiral Grace Hopper and her team at Remington Rand in 1952. It’s designed to develop portable business applications that could be run on systems developed by multiple manufacturers.

It remains vital to the world’s financial systems because of its simplicity and reliability.

One measure of its importance is the number of news and commentary articles published in reliable industry sources that repeat a common theme, namely that the programming language is ancient, nobody wants to use it, but it’s so vital to the financial and government sectors that it won’t go away – COBOL is dead! Long live COBOL!

Once or twice a year a new piece pops up and we typically pass it around the office, discuss new information or opinions it reveals, and archive it.

Recently, one of our shrewd colleagues suggested we post links to these articles here on our website so others in the small but influential COBOL community can reference them.

So we did. We’ll update this page when we discover new COBOL media pieces. If we’ve missed something important, email [email protected].

Long live COBOL!

Articles

2020
Title Date Author Snippet
The code that controls your money November 10, 2020 Clive Thompson
Tech Journalist		 COBOL underpins the world's financial systems, and it's not going away soon.
Why the Government Is Desperate for Programmers Who Know This Old Language April 9, 2020 Caroline Delbert
Popular Mechanics		 As the U.S. grapples with the economic fallout from the COVID-19 pandemic, government agencies with aging systems are clammering for COBOL developers.
A lazy fix 20 years ago means the Y2K bug is taking down computers now January 7, 2020 Chris Stokel-Walker
New Scientist.com		 A quick but lazy fix to the Y2K bug is now putting the same systems in danger.
2019
Title Date Author Snippet
How COBOL still powers the global economy at 60 years old may 23, 2019 Paul Flahive
Texas Public radio		 Financial institutions continue to rely on COBOL code, but will new training programs be enough to replace the retiring workforce?
SHARE: GAO’s Mainframe Risk Claims Debunked May 9, 2019 SHARE'D Intelligence The 2018 GAO Report that says government systems are at significant risk due to their reliance on legacy programming languages is nonsense. Evolving architecture is always bridging the gap between older and modern applications.
2018
Title Date Author Snippet
Quartz Obsession: COBOL June 28, 2018 Justin Sablich What's going to happen when all the Baby-Boomer COBOL developers retire?
In digital transformation top banks are leading April 3, 2018 Tom Groenfeldt Instead of ripping and replacing legacy systems and code, which can be prohibitively expensive and time consuming, some banks are maintaining these systems and wrapping customer engagement systems around them.
It’s Cobol all the way down April 2018 Glenn Fleishman COBOL-based systems continue to run much of the world’s financial systems. But its supporting workforce is retiring and efforts to convert these applications to modern programming languages are expensive and time-consuming.
2017
Title Pub Date Author Snippet
COBOL is everywhere. Who will maintain it? May 6, 2017 David Cassel Many of the world’s financial institutions and U.S. government agencies, such as Homeland Security, Department of Veterans Affairs, and Social Security, rely on COBOL-based systems, but a shortage of programming talent and education institutions that provide programming courses is on the horizon.
Trump said government has one 40-year-old IT system. It actually has at least 10. April 12, 2017 Frank Konkel A list of 10 U.S. government computer systems that are at least 40-years old. Three of the systems run on COBOL code.
Banks scramble to fix old systems as IT 'cowboys' ride into sunset April 9, 2017 Anna Irrera
Reuters.com		 Organizations that rely on Cobol-based applications have a hard time replacing retiring programmers and support personnel, which has given veteran developers opportunities to continue working, even after retirement.
2016
Title Date Author Snippet
Why it’s time to learn COBOL April 1, 2016 Paul Rubens
CIO.com		 Acquiring COBOL programming skills might be a wise career move. Hundreds-of-billions of lines of COBOL code are still in use and many universities have stopped offering classes in the 50+ year old language.
2015
Title Date Author Snippet
The inevitable return of COBOL July 6, 2015 Ritika Trikha
HackerRank		 The looming shortage of COBOL programmers will inevitably lead to COBOL programming once again becoming an in-demand skill set.
2014
Title Date Author Snippet
CIOs should prepare for lack of Cobol (Yes, Cobol) developers October 2, 2014 Sharon Florentine
CIO.com		 While the demand for talented and skilled Cobol programmers remains steady, the programming language’s lack of popularity has shrunk the available talent pool. As the existing Cobol support workforce ages and retires, companies are resorting to novel strategies to acquire and train staff.
Cobol is dead. Long live Cobol! October 2, 2014 Gary Beach
Wall Street Journal CIO Journal blogs		 CIOs that rely on Cobol-based systems keep developer staff as long as possible while others prefer new hires with multi-language capabilities over Cobol-specific or Cobol-only skills.
All the rich kids are into COBOL – but why? September 17, 2014 Matt Asay
readwrite.com		 COBOL isn’t sexy or even that popular. But the basic tenants of supply and demand remain true – if there are still a lot of COBOL applications running critical systems and not a lot of programmers interested in learning the 50-year-old programming language, then brushing up on your COBOL skills might make it easier to find a job earning more money.
The government’s COBOL conundrum June 2, 2014 Nicole Blake Johnson
FedTech magazine.com		 The U.S. federal government’s Office of Personnel Management released its “Strategic Information Technology Plan” for revamping the agency’s IP operations. Part of the plan discusses the office’s plans for maintaining and eventually migrating away from the roughly 60-million-lines of production COBOL code that enable the agency to meet a number of its regulatory requirements.
2012
Title Date Author Snippet
Brain Drain: Where COBOL systems go from here May 21, 2012 Robert L. Mitchell
CIO.com		 Not only does losing experienced COBOL programmers hurt many companies’ ability to maintain its mainframe systems, but it also means the loss of the programmers’ deep understanding of the business logic. A number of organizations are teaming with private businesses to educate younger programmers and team them with experienced developers before it’s too late.
Cobol brain drain: Survey results March 14, 2012 Compuworld Staff Results from the Compuworld survey on Cobol use in business and government, which showed that nearly 50 percent of respondents had operational Cobol-based systems and a large number continue to develop new business applications with Cobol.
The future of COBOL: Why it won’t go away soon – Part 2 January 11, 2012 Brian Bloom
IT World Canada		 When thinking about maintaining or replacing their COBOL systems, companies must consider the employee angle. Can they continue to hire COBOL programmers when experts forecast that a major COBOL skills gap in on the horizon, and is that enough of a reason to rip and replace?
The future of COBOL: Why it won’t go away soon – Part 1 January 10, 2012 Brian Bloom
IT World Canada		 COBOL-based systems will not be going away anytime soon because of the millions of invested man-hours and dollars already spent to develop these mainframe programs and the enormous predicted replacement costs. There’s also the fact that we don’t have anything better enough to make the change.
Fun

*All images are copyrighted by their respective owners

Todd Erickson is a tech writer with Phase Change. You can reach him at [email protected].

Published by Phase Change Staff in Community
Tags: cobol, cobol brain drain, community, developer-engineer, humor, industry turnover, legacy systems, living post, software development, system knowledge
Featured Image

July 10, 2017

Phase Change will bridge application knowledge silos

July 10, 2017

by Todd Erickson

Members of Phase Change's management team address how our technology will bring together an organization's siloed application knowledge to enable faster responses to market demands.

It's a paradox. Your most successful applications get larger and more complex with updates, upgrades, and new features until they become difficult to change and adapt. Now they are hard-to-manage legacy systems that cost ever more time and money to remain valuable.

One of the main reasons applications become difficult to maintain is that knowledge silos emerge – where various people in development and other departments understand small portions of the code, but no one person knows the entire code base.

Then when you bring people together to develop new features that will address market demands or opportunities, each contributor only knows his or her portion of the application code, each person has his or her own mental model of the code, and all of that knowledge is difficult to share.

Learn how Phase Change's assistive AI agent will bridge knowledge silos by understanding the entire code base, presenting a complete and accurate model, and collaborating with engineers and stakeholders.

Todd Erickson is a tech writer with Phase Change. You can reach him at [email protected].

Published by Phase Change Staff in Applied, Technology
Tags: artificial intelligence, assistive AI, brad cleavenger, business agility, gary brach, ken hei, legacy systems, productivity, project team, software development, system knowledge
Featured Image

May 25, 2017

Why is COBOL cool again? – blog

May 25, 2017

by Todd Erickson and Elizabeth Richards

Discover why the recent spotlight on COBOL systems and the shortage of qualified COBOL programmers isn’t due to a lack of qualified engineers, it's due to a lack of knowledge.

At Phase Change, we pay attention to legacy systems and their challenges. So, why was a mainframe language developed in 1959 suddenly the topic of multiple news articles?

Reuters and The New Stack recently published articles about COBOL, an often-overlooked programming language that was developed before John F. Kennedy became the 35th President of the United States.

Organizations like the Department of Veteran Affairs and large financial companies, such as Bank of New York Mellon and Barclays PLC, are examples of the types of institutions that rely on COBOL applications for nearly $3 trillion worth of daily transactions. But they’ve used COBOL for decades, so, that doesn't explain the recent attention.

A little history

The U.S. government developed the common business oriented language (COBOL) in conjunction with Rear Admiral Grace Hopper and a coalition of industry and higher-education envoys. It's simplicity and portability have stood the test of time, and are the main reasons why 50-year-old COBOL applications continue to play a critical role in finance, banking, and government operations. That plus the inertia that characterizes large, critical systems.

It's because the engineers that maintain COBOL-based systems are leaving the workforce, there aren't qualified developers available to replace them, and these institutions are freaking out. The COBOL brain drain is threatening the organizations that economies are built upon.

Brain drain refers to how departing software engineers leave with all of their system and domain knowledge supposedly locked away in their brains. That knowledge is thought to be lost from the organization forever.

The average age of a Cobol programmer is somewhere between 45 and 60 years old and they are retiring. The problem is that few programmers are interested in replacing them, and the availability of COBOL training resources has dropped precipitously because it's just not a cool language anymore.

We won't repeat all of the statistics that show how much COBOL code is still in use and how important those systems are. Read the Reuters and The New Stack articles, which both mirror a series of comprehensive feature articles published by ComputerWorld in 2012. The metrics and themes haven’t changed much.

Basically, these companies have three options to deal with Cobol brain drain, and all involve high risks. First, they can simply replace their COBOL systems with systems built on more modern programming languages. That project took the Commonwealth Bank of Australia 5 years and $749.9 million, which was 30% over budget. The risk associated with implementing such a massive new system has kept most financial institutions from doing it.

Second, they can engage consultants like the Cobol Cowboys, or hire and train new programmers to support their COBOL systems. This option also involves a great amount of risk because companies have to find engineers that have the skills and interest to support COBOL applications, and then hope they can unravel the layers of modifications and system integrations that accrue with five decades of maintenance, usually with little documentation.

Third, they can completely stop modifying core systems that nobody understands, but are too critical to risk changing or replacing. The USDA faced that choice.

It's not a people problem

But from our perspective, the issue is not a human-resources problem. The companies that rely on Cobol-based systems don't lack the right people, they lack the right knowledge.

If the new engineers assigned to work on COBOL-based applications could access the departing developers' system and domain knowledge, or better yet, all of the programming and domain knowledge imbued into the system from prior engineers, imagine how much easier it would be for them to comprehend these complex systems. It would be like having a personal mentor always available — even while the previous engineers are off enjoying retirement.

That's why this is a knowledge problem and not a people problem.

It's a huge opportunity for someone that can reach all of that trapped knowledge and make it easily comprehensible.

Exploiting the knowledge left behind

Phase Change's objective aim is to use our assistive AI technology to unlock all of the trapped programming and domain knowledge – as well as the human intent behind it – inside software applications, no matter which programming languages were used to create them, and make it easy to access that knowledge with natural-language interaction.

Engineers and stakeholders will literally talk to their software applications to reveal the hidden encoded knowledge they require to comprehend the overwhelming scale and complexity resulting from decades of modifications and system mergers, and hundreds of contributing developers.

Unlocking the encoded knowledge that's trapped in COBOL system will give these large institutions the knowledge they need to make informed decisions about their legacy systems.

learn more about our technology

Todd Erickson is a tech writer with Phase Change. You can reach him at [email protected].
Elizabeth Richards is Phase Change's director of business operations. You can reach her at [email protected].

Published by Phase Change Staff in Applied, Technology
Tags: blog, brain drain, cobol brain drain, Grace Hopper, legacy systems, programmer shortage, skills gap
Newer Posts

Contact

651 Corporate Circle
Suite 209A
Golden, Colorado 80401
Phone: +1.303.586.8900
Email: [email protected]

© 2024 Phase Change Software, LLC