All Posts in Applied

April 9, 2021 - No Comments!

Phase Change President: Creative & focused AI needed to help COBOL skills shortage

The so-called "COBOL Skills Shortage" is compelling many organizations to impetuously hire and train programmers to maintain, support, and attempt to modernize their COBOL systems.
But understanding how to write COBOL is not enough — developers have to comprehend what an application actually does and how code changes can impact the system as a whole to avoid critical missteps. That work for those developers is cognitively difficult.

Phase Change President Steve Brothers recently wrote an article for Built In about how artificial intelligence (AI) can help solve the application knowledge gap problem, but only when traditional AI technology gets more creative and moves beyond understanding general business knowledge and instead learns specialized industry and institutional domain knowledge.

AI & software development

AI can help solve the application knowledge gap dilemma, but popular contemporary AI approaches are insufficient. Some AI tools can help with the syntax of writing code, but these remedies only provide incremental value.

Developers spend nearly 75 percent of their time finding the area in the source code in which they need to make a change because understanding code in these large complex systems is difficult and time-consuming.

AI will emerge as a paradigm-changing technology when it can understand code intent and “reimagine” computation into concepts, thereby doing what a developer does when they code — but at machine speed.

Read Steve’s entire Built In Colorado article at

February 24, 2021 - Comments Off on Legacy system failures expose the application knowledge gap’s harmful risks

Legacy system failures expose the application knowledge gap’s harmful risks

February 24, 2021

by Steve Brothers

Government system failures during the rush to provide public benefits to alleviate the economic effects of the COVID-19 pandemic publicly exposed the mainframe knowledge crisis that also threatens financial institutions, healthcare providers, and many other organizations foundational to the world economy.

Several states discovered the knowledge-gap’s potentially devastating consequences when waves of unemployment-claims poured into their systems as COVID-19 ravaged the economy in early 2020. The states’ unemployment computer systems crashed trying to process the deluge of claims using mainframes and decades-old programming languages.

But it wasn’t the mainframes or the legacy programming languages that failed, despite what you may have read. It was the lack of available expert programmers necessary to maintain and update these systems to handle the voluminous claims.

According to The Verge’s article, “Unemployment checks are being held up by a coding language almost nobody knows,” Colorado employed exactly one full-time programmer to maintain the state’s COBOL system prior to the pandemic. Back then, Colorado processed roughly 2,000 unemployment claims per week. In March and April 2020, that number rocketed to as high as 104,572 claims per week.

Now governments, non-profits, and private organizations are reviewing their systems’ strategies to learn from these mistakes. If your business relies on legacy systems, you probably should keep reading – and schedule some time with your IT people.

Mainframes are cornerstones

Legacy mainframe systems and software bedrock many of our most trusted institutions, including government services, finance and banking, healthcare, and insurance. In a substantial number of cases the expert developers that created and maintained these systems and software are retiring without a supporting workforce to replace them.

Besides the people that make your business run, your software is potentially the most important resource your organization has. Internal applications likely drive your employees' capabilities and productivity. Customer-facing programs attract new customers, close business deals, and increase revenue. New applications and features can open new markets and opportunities.

To maintain and improve your critical applications, your software team relies on individual engineers that developed an expert understanding of your programs through years of experience. They know the applications and all the accumulated system changes and challenges.

When those experienced engineers depart your business, the developers that replace them must acquire the same application knowledge through training, mentorship, and on-the-job programming. This exercise introduces several material business risks.

Learning on the job

Developers new to software applications typically require 6-12 months of on-the-job learning to become productive, depending on the size of the source code base. To become proficient, programmers may need up to 3 years.

Without qualified software developers knowledgeable about your applications, you endanger your business's operations, reputation, and security. You also risk a significant decrease in your software teams' productivity and efficiency.

Consider the monumental task confronting newly hired or transferred IRS developers last March. Congress passed the CARES Act on March 25, 2020, and then Treasury Secretary Steven Mnuchin announced that individual stimulus checks would be mailed in early April.

To assist with the delivery of economic stimulus payments, the new developers were required to immediately start working with the agency's source code base, which, in 2019, was estimated at nearly 20 million lines of code and includes over 60 years of legislative and system changes. As of mid-May 2020, nearly 20 million people had not received their stimulus checks, and some recipients had problems throughout the year.

These engineers didn’t have 6-12 months to become productive. They had to hit the ground running on day one. And without the benefit of weeks or months of training and on-the-job learning, they didn’t have the application knowledge necessary to understand how even simple changes could affect entire applications.

And let's not forget the productivity loss due to the remaining IRS's experienced engineers for training, mentoring, and supervising the new recruits.

What’s your risk?

Your situation may not be as dire as what the IRS faced – for now. But how much time can you really give your new developers to learn the system, and how much productivity can you afford to lose while your experienced programmers train and supervise them?

How much do you trust the developers that have just started working on your critical applications?

How confident will you be when your CEO or Board of Directors asks for assurances that the next customer-facing application update will not result in outages and lost revenue – especially if the update was programmed by a developer you hired just weeks ago?

Your software is a critical part of your organization, especially if you rely on legacy mainframe systems. You must have a plan or tool that keeps the code running and bridges the gap between retiring and departing developers and the people that will replace them.

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

October 23, 2020 - Comments Off on Modernize your mainframe instead of migrating away for higher customer and company satisfaction says IDC study

Modernize your mainframe instead of migrating away for higher customer and company satisfaction says IDC study

October 23, 2020

by Todd Erickson

Modernizing your IBM mainframe instead of migrating off the platform leads to higher customer and company satisfaction says and IDC study of 440 organizations in Australia, India, New Zealand, the United Kingdom, and the United States.

Commissioned by Rocket Software, a legacy infrastructure consulting firm, the study as reported by IT Jungle found that IBM shops that modernized their IBM mainframe infrastructure instead of migrating to more modern platforms were more satisfied across a number of metrics before and after the projects.

The shops that modernized reported higher satisfaction than the shops than migrated across the following 7 metrics:

(1) customer experience;
(2) overall performance;
(3) security, availability, and disaster recovery capabilities;
(4) agility, microservices, and DevOps;
(5) ease of finding talent;
(6) ability to incorporate AI and IoT;
(7) and API, mobile, and Web enablement.

According to the study report, in addition to seeing higher satisfaction ratings, the organizations that modernized generally reported paying less on hardware, software, and staffing.

The study seems to dispel the common IT industry myth that mainframe platforms are less capable than more modern systems simply because of their age.

Todd Erickson is a Technology Writer with Phase Change. You can reach him at

May 28, 2020 - Comments Off on Can AI solve the engineer shortage?

Can AI solve the engineer shortage?

May 30, 2020

by Todd Erickson

The COVID-19 pandemic has revealed workforce shortages in a number of industries, including healthcare, food retail, and cybersecurity.

The related financial crisis and government financial assistance requests have also demonstrated a critical need for legacy system developers. The recent performance issues experienced by these financial assistance programs have exposed how dependent our financial and public infrastructure are on legacy and mainframe systems.

Phase Change COO Steve Brothers recently penned an article for ColoradoBiz Magazine about how the legacy application skills shortage threatens the software that underpins a great deal of the world's large financial and government systems.

He also talks about how artificial intelligence (AI) can be extremely effective in helping legacy application maintenance and development by introducing automation into the process, improving project management efficiencies, and by shortening the steep training curve typically experienced by developers new to these systems.

Learn more about how the improved productivity and efficiency AI brings to software development could be instrumental in maintaining and improving our critical legacy and mainframe systems.

Can AI solve the engineer shortage?
by Steve Brothers
ColoradoBiz magazine
May 15, 2020

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

Todd Erickson is a Technology Writer at Phase Change Software. You can reach him at

May 8, 2020 - Comments Off on Colorado Inno profile explains how AI agent improves developer productivity

Colorado Inno profile explains how AI agent improves developer productivity

May 8, 2020

by Todd Erickson

Colorado Associate Editor Nick Greenhalgh recently interviewed Phase Change President Steve Brothers for a profile story titled, "Golden startup's AI aims to make developers more efficient," that explains how our technology operates as a subject-matter expert and will improve software-developer efficiency and productivity, especially for industries that rely on enterprise software.


Todd Erickson is a Technology Writer at Phase Change Software. You can reach him at

April 1, 2020 - Comments Off on IRS stimulus-check delivery faces knowledge gap challenges

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

December 11, 2019 - Comments Off on How short-term maintenance practices can double application size in 5 years

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.


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
Todd Erickson is a Technology Writer with Phase Change. You can reach him at

April 24, 2019 - Comments Off on The cost of fixing COBOL bugs

The cost of fixing COBOL bugs

April 24, 2019

by Greg Brueggeman

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 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.

*Greg Brueggeman is the Director of Product Management at Phase Change Software. You can reach him at

February 11, 2019 - Comments Off on Phase Change CEO Steve Bucuvalas featured on the InfluenceNow! podcast

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
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.

August 4, 2017 - Comments Off on Phase Change enables market adaptability through impact analysis

Phase Change enables market adaptability through impact analysis

August 4, 2017

by Todd Erickson

Gary Brach, Ken Hei, and Brad Cleavenger discuss how Phase Change's assistive AI removes the doubt associated with changing software applications.

Changing software is difficult and expensive, and it can be a major stumbling block to business innovation.

Phase Change's assistive AI will enable software teams to quickly and fearlessly address market opportunities by rapidly assessing the scope and viability of proposed software modifications, and then efficiently making changes without adding the technical debt that reduces system performance and application life span.

Todd Erickson is a tech writer with Phase Change. You can reach him at