Colorado Inno.com 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.
Read more at ColoradoInno.com.
© 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
Discover how software developers are like archaeologists, and why understanding source code – the key to software development – involves a lot more than digging.
Software engineers are often called developers. However, according to a number of experienced programmers, they spend the great majority of their time (78%) simply searching and understanding existing software, and the rest of their time (22%) actually modifying legacy software or developing new applications.
Programmers are forced to spend so much time finding and comprehending code because current tools and techniques are not technically savvy, and they are too focused on the searching process. They don't help developers understand how the code works together within the systems they serve.
In fact, a recent blog post compared the source-code searching process to archeology. It's a reasonable analogy given that the tools developers use are only slightly more advanced than rudimentary shovels and brushes.
Why is software development – an activity that's driving incredible technological change – so far behind the curve in building tools that help programmers comprehend the code they work on?
Searching for ancient relics and specific lines of code are both complex processes.
An archeologist doesn't use a bulldozer and dig in random locations. She researches excavation sites and uses advanced technology, such as satellite imagery to find optimum exploration locales and ground-penetrating radar for mapping. Then she carefully and methodically removes topsoil while analyzing and recording each artifact down to the smallest pottery shard.
Every relic she unearths builds her knowledge of the site, and the people and culture she's investigating. For example, the archaeologist may assemble a handful of pottery shards into a serving dish, which she studies alongside other artifacts to better understand an ancient culture's family meal rituals. She can easily share the dish with other scholars and store it for future analysis.
Each discovered artifact may also modify how she approaches the rest of the dig.
In software development, Professor Vaclav Rajlich asserts that the processes of searching and understanding code require two phases called concept location and impact analysis. Concept location involves finding the lines of code to be modified and the relevant but disjoined source surrounding it.
Impact analysis examines how a proposed modification will impact the entire application, including performance, stability, intent, and secondary consequences in distant modules. Poor or incomplete impact analysis can lead to more bugs.
In essence, a developer spends his time in active knowledge construction, building an integrated mental model so he understands how a system is constructed and its purpose and intended results. Only then can he be confident enough to make changes.
Errors logs, debuggers, and grepping assist developers in finding specific lines of code – his shards of pottery. But the developer must reconstruct the code into the mental models necessary for understanding the system. And these models remain locked away in the developer's mind, making them difficult to share and retrieve over time.
But it doesn’t have to be that way. Phase Change’s technology will transform how developers search and understand source code and applications. A programmer will no longer have to manually and laboriously search and play connect-the-dots to build mental models.
We are developing assistive artificial intelligence (AI) that automatically analyzes source code and understands the human intent behind it, creating immersive application-visualizations that resemble a programmer’s mental models. These visualizations can be stored, retrieved, and shared similar to how an archaeologist saves and shares the artifacts she assembles.
A developer will collaborate with our AI agent using natural language to effortlessly locate source and move quickly beyond simply identifying concept locations to performing comprehensive impact analysis. He will be aware of every effect his modifications bring about, and work confidently with a rich understanding of the code and the application.
Because the goal isn't to search, it's to understand.
Elizabeth Richards is Phase Change's director of business operations. You can reach her at [email protected]
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.
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.
Elizabeth Richards is Phase Change's director of business operations. You can reach her at [email protected].
Learn how Phase Change's assistive AI creates scale-free software engineering and enables the development team to swiftly respond to market demands.
As software systems grow in size and complexity, they can easily become incomprehensible for individual engineers. They simply get too large and sophisticated for one person to fully understand. As more people are required to comprehend and maintain complex systems, the organization's ability to modify those systems and respond to changing market dynamics diminishes.
Watch President Gary Brach, Director of Engineering Ken Hei, and Senior Software Architect Brad Cleavenger, discuss how system scale affects the ability to modify applications and meet market demands, and how Phase change's assistive AI minimizes scale issues to create scale-free software.
Phase Change Software
13949 W. Colfax Ave
Building 1, Suite 205
Lakewood, Colorado 80401
Phone: +1.303.586.8900
Email: [email protected]
© 2025 Phase Change Software, LLC