Women of COBOL Episode 3: The Case for Modernization
Misty Decker: Hi and welcome to Women of COBOL, our third episode, today. We are going to be talking with Marianne Bellotti—the author of my favorite book, “Kill it with Fire”; if you don’t have it, you need it—and Susan Drennan, vice president of COBOL sales at Micro Focus. We’re going to be talking about modernizing COBOL applications. So let’s start with some quick introductions. Marianne, tell us a little bit about yourself.
Marianne Bellotti: Yeah, hi everybody, my name is Marianne Bellotti. I am an author, an engineering manager and software engineer. I’ve been doing the type of work that I do for about 20 years and I tend to focus on large, complex systems: maintaining them, operating them, different failure modes on then which for a large period of time I was working in the federal government. Involved a lot of COBOL but isn’t necessarily exclusive to only COBOL.
Misty: I love that point. We are going to circle back to that one, I think. Susan, tell us a little bit about yourself.
Susan Drennan: Sure thing. I’m Susan Drennan. As you mentioned, Misty, I’m the vice president of sales at Micro Focus for our COBOL solutions and that covers North America, so Canada plus the United States. I’ve been at Micro Focus since 1996, always in what we consider the kernel of technology of this company, which is our COBOL development and deployment solutions. I did take five years off in the early 2000s—I stayed home with our three small children—but came back in 2008 and really have been enjoying supporting our customers, our partnerships and really representing what I think are some of the best products in the legacy modernization space. So that’s what I do [laughs].
Misty: So I see a whole lot of intersection between the two of you because you know, Susan, you’re selling solutions and you’re helping customers with the tools and things that Micro Focus has to offer, and Marianne for a long time you were a receiver of that technology. So the whole premise of Women of COBOL is that we give women from various aspects of COBOL in this world a chance to chat with each other. So how about if we dive right into why modernize COBOL applications rather than just getting rid of it altogether and starting over?
Marianne: Do you want me to start with that?
Misty: Yeah, you guys just jump in. We’re doing this.
Marianne: The thing I always go back to is what can you actually run. Like what can you actually operate and keep up and running and like, for the efficiency and effectiveness of your business, right? For some organizations that answer might be just sticking with COBOL because you don’t actually have the expertise in the other alternative languages, so you would end up doing a lot of outsourcing, you’d end up doing a lot contract work which would leave you with a system that you don’t know how to run or maintain, which is much, much worse than the numeric age of your system. But for other organizations that picture is going to look different, so the number one priority has to be what can we operate, what can we maintain and what technology is right for us, rather than COBOL or not COBOL?
Susan: And I would add to that, I completely agree. What we see with our customers primarily is we can provide them a modernization path that is low-risk because they aren’t ripping and replacing or rewriting to some newer language. It’s high-reward because they are currently working with technology and applications that they have spent years customizing to their necessary industry differentials and it allows them over time to make incremental steps in modernization versus a big bang effect, which again brings up the concept of risk and cost. We’ve seen many of those sorts of projects get launched and fail, some taking years to fail and that’s obviously an expensive proposition for any organization. Our thoughts really are work with what you know, work with what you have, keep your industry differentials, don’t throw out what you’ve spent years building, and we have a path for you that can support that journey. I don’t want to turn this into a commercial for Micro Focus, but we do spend an awful lot of time supporting COBOL as a language and investing in development s0lutions around it. So I feel somewhat like I represent the custodian of COBOL in a distributed environment moving forward, which is a great place to be these days.
Misty: Yeah. This idea of fails really has me really interested because I was presenting at a conference recently and I had several people come up to me and say “I don’t know why you’re talking about moving COBOL applications to another platform.” Back in 1987 there was this bank that tried to do this and it failed spectacularly. You know what are those failures and why are you seeing about why is it different today, or is it different today? Marianne you worked a lot in government, which is famous for failures, so let’s start there [laughs].
Marianne: No one does large complex software failure the way the federal government does large software failure. I think what’s interesting about software is that—so everybody knows Moore’s law, which is this idea that over time, hardware gets cheaper and smaller. But there is a different corresponding unnamed role, which is software gets more and more complex and expensive. And so a lot of times when we go into a system and we look at the COBOL, we’re just looking at one part of a much, much larger system of things built on top of the COBOL, right? What’s very interesting to me, as somebody who has like primarily a background in social science before [becoming an] IBM software engineer, is that the human process was there first. Then we digitized the human process, then the human process adapted to the digitalization and the digitalization adapted to the new human process, and there’s just sort of this feedback, right? And so a lot of times what dooms software projects to failure, this sort of rip and replace model, is incorrectly assuming that the software that existed that was built in—let’s say the 60s is an accurate specification of what the system is actually doing, right? So the rip and replace model really breaks down when you’re not coming to it honestly, when you think to yourself like, everything has been solved, we have figured this all out. All we have to do is just take the code and rewrite it in another language. If you’re going to go that route, you really need to invest in it and rethink exactly what this system is trying to do, like what the conditions and context around what it’s trying to do are, and then using that Agile methodology of like, what is the minimum viable thing that we can like establish that is valuable to the company, and work your way up. But a lot of times, because it is an operational system, people are impatient with it. It’s not glamorous or sexy to rebuild the system from the ground up, it’s glamorous and sexy to do something new. So they don’t to do that. They don’t want to invest the time and effort, like really approaching it that way, and the irony of it is it ends up costing them way more money and way more time than it would have if they’d actually just decided to take a more user research, Agile-based approach to thinking about the problem.
Misty: Right.
Susan: I think we should name that unnamed law the Bellotti law [laughs]. How do we feel about that? Can we vote?
Marianne: I mean, you suggested it. I will not turn down the honor.
Misty: I think of the people who have a voice right at this moment, it’s unanimous.
Susan: Okay, good. Good, good.
Misty: We’ll do that. Susan, what are the things that you did for those failed projects?
Susan: Well, you know the one—
Misty: I mean, we haven’t had any failed projects that would—
Susan: Oh gosh, no, never. The one that most recently comes to mind and probably got the largest press was when we were all heading into Covid shutdown and the unemployment system of the state of New Jersey hit the skids. I don’t know if you all recall this, but—
Misty: Oh yeah.
Susan: The governor of the state, I think stated that the problem was COBOL. COBOL was old and lousy and COBOL failed and people can’t get their unemployment claims because of COBOL. And what we really find is you know, anybody with any knowledge of software and infrastructure, etc., will know that it’s typically not the language that’s the problem, right? It’s the infrastructure and the possible delayed maintenance and enhancement of the volume of processing needs necessarily to run an unemployment system that gets hit with 100-fold claims to a normal situation, right? We did work, actually with various states. I won’t get into whether New Jersey or not New Jersey, but many states had a lot of unemployment claim processing issues, and frankly when we speak with our state customers, their issues are all around infrastructure, cost reduction, and security, and if you put those three things together, we can help modernize those environments. COBOL can live in those environments and bring value today. It’s really typically not a language issue, so I guess I’m getting a little off track on your question about failures, but we’ve seen them, we’ve supported the recovery from them, and you know in some cases, we’ve got partners that specialize in sort of rescue missions into areas to get somebody back on track.
Misty: I thought you were going to say we have partners that specialize in failed projects [laughs].
Susan: Well, we do that, yeah.
Marianne: There’s a really important point that is just innate, in that the problems that people observe and attribute to COBOL are broadly found in a wide variety of languages if not all languages, right? Like it’s almost never COBOL in and of itself that just breaks one day. It breaks because someone attempted to change something and didn’t understand the full impacts of the system. Why is that? Well, you didn’t have any documentation. You didn’t have any form of integration testing to see like what is the expected behavior and like what is the outcome of this change? That’s very common in older COBOL programs because that wasn’t the convention, that this wasn’t the standard in engineering at the time. That was a thing we learned through hard, hard experience that we should always do, but at the same time you can find applications that were written yesterday that all of those things are true for. It has very little to do with the language.
Misty: I love your website, Marianne, with the quote that says “secretly, all software development is legacy modernization.” Because the second it goes into product, it’s instantly legacy.
Marianne: Right.
Misty: I do remember the New Jersey thing because it made me very angry. I like to say—and it was my birthday—and I like to say that you can write garbage in any programming language. It doesn’t have to be COBOL to be a bad application. I actually wrote to a tech reporter “if you’re going to write about COBOL, you might want to do five minutes of research first.” I was so mad that—
Marianne: Oh Misty, you can’t take it personally if you’re in the world of COBOL. I mean, come on. We are the butt of many a joke.
Misty: Oh, I know. I’ve been in this space for 30 years. I know. So the guy wrote back everything about mainframe screams Sith. So I changed my Twitter name to “Darth Misty, the Mainframe Sith.” That has been the best move I’ve ever made in my life because it gave me a platform to speak the truth, which I’ve been doing ever since.
Marianne: Yeah.
Misty: That was a good day for me. So there are a lot of misconceptions about COBOL, and we can save that for another Women of COBOL, but what I’d really like to talk to you guys about—because you have so much experience—how do those misconceptions lead to bad business decisions? Give us some examples, without the names, of misconceptions leading to bad, bad decisions.
Susan: I think what’s underestimated is the internal sales pitch, right? If you are a director of a division, or even just an engineer within a corporate environment, you need to sell the things you want prioritized up the change of command. There’s an infinite number of things an organization could invest in a quarter, in terms of money and people resources and intention. And so a lot of times software engineers, who do in fact know better, will use these myths to sort of create that sales pitch. Like, “I need this money to go here on our maintenance efforts. Oh, there’s COBOL over here. That’s a thing I can scare everybody to death over it. I’ll just go like, ‘there’s COBOL here. There’s COBOL. We need to get rid of it immediately.'” So I feel like a lot of technology decisions are ultimately a matter of like, internal lower-case people politics, right? The things that you have to do to build momentum and persuade people that your approach and the stuff you want to accomplish is the right thing to accomplish, it ends up being in some cases an own goal because by simplifying it and making it easier to sell and communicate up the chain of command, you’ve also created an inaccurate picture of what success really looks like.
Marianne: Yeah.
Misty: I love that. I want to give you an example, if I can jump in here. We just did an interview with AG Insurance. They just did a massive mainframe modernization project and we asked, what are your top three reasons why it was successful? And what one of his top reasons was that he launched an internal advocate campaign, and it was a marketing campaign internally to get everyone on board with the project. He said you’ve got to get everybody in agreement to moving on it. I think he called it modernization advocate program or something like that, inside the company.
Susan: Yeah, yeah. It’s like a thing I teach my engineers all the time when they’re thinking about how they scope their project. You need to budget a period of time for evangelism—whether that is sitting, going one on one, pairing with other engineers—showing them how to use the thing you just built or socializing it higher up or whoever the audience is. You cannot just expect the Field of Dreams scenario: you built it, now everyone understands and appreciates the value of it, right? You have to really put the time and effort into thinking about that.
Marianne: That’s really interesting and it kind of talks to the bias that you have to overcome before you even get to building out your project plan. I was speaking with one of our partners today. He is a small independent software shop that writes an application that deals with land management. It’s sold into counties and states, and we were talking because he has got a couple challenges on his plate but he said—one of the crazier ones is if they think it’s COBOL, they won’t take my meeting.
Misty: Wow.
Marianne: We don’t want COBOL. Oh no, no, no. No, that’s not going to work for us. He says “well, you haven’t even seen my software in action. You don’t know what it does.” And if he can get them past that immediate bias, he typically gets the sale. His business is expanding. He’s got what’s really about a 20+ year old environment that’s he’s continued to modernize and sell into our state governments or land management, and his biggest inhibitor is that five-letter word. They’re just not sure what to do with that when they realize that even the database is COBOL. It’s not even SQL.
Misty: Wow. I need to pause for one second because the sun is setting and you can’t see my face anymore so just-
Marianne: You’re glowing [laughs].
Misty: I’ll have a new woods background. Oh, it will look, like someone will spot it, I’m sure. Someone will be like, “wait. that tree wasn’t there.”
Marianne: Good stuff.
Misty: Well that’s better. Okay so yeah, it’s a really topic about these social dynamics that go on and it makes so much sense to me that—sadly—a customer wouldn’t even take a meeting if they think the application is written in COBOL when that’s just a construction material, right?
Marianne: Yeah.
Misty: It has absolutely nothing to do with how the program operates, but I’m reminded, Marianne—I was introduced to you before this book. You wrote an article about how COBOL actually has an advantage when it comes to financial calculations. Without getting super, super technical, do you have a way of summarizing that article?
Marianne: Yeah. It was basically a discussion of fixed versus floating point calculations and how you can do the math on either system, but you have to be prepared, you have to know you’re using that system and prepare for the consequences of moving from one to the other. Because when we think about things in fixed point, there are a different set of concerns when we’re doing these kind of financial calculations than there are with a floating point technical system. And what was particularly relevant for financial systems is that if you get it wrong, you end up with a rounding error, but you end up with a rounding error that’s like something like, I don’t know like an eighth of a penny, which may seem completely insignificant, except that financial calculations feed other financial calculations, which feed other financial calculations. So these tiny, tiny, tiny little losses inaccuracy eventually cascade up to really serious outcomes, really incorrect results. So I was kind of exploring the space here and what people’s awareness of this issue were and their preparations, and then some of the interesting theories that I had been exposed to around overall performance. Because in a lot of “modern” programming languages, there are the libraries to do fixed point arithmetic, but they’re not considered a standard library, which means you have to import it and the whole dynamics of how imports actually work in language systems and like the little tiny nanoseconds of transaction time you might use every time you use a library and scaling that up, can you see a performance impact? It was an interesting sort of like thought experiment to sort of inject these types of scenarios into the conversation, particularly for an audience that is used to just going, “well we’ll just put it in Java and everything will be fine,” to sort of say like, “not necessarily.” You can do it, but you have to know what you’re getting into.
Susan: Yeah, I would agree and I would say as somewhat of an evangelist of the language, we don’t recommend you use COBOL for everything. You’re not writing your front end in COBOL, but you’re utilizing it for what it does best and you hit one, which is math calculations. I think you also mentioned performance and processing. I mean it’s kind of what it does best is it’s just a massive engine that’s going to crank out a really accurate response in a really rapid pace, so it seems great to me.
Marianne: I would really love for there to be a wider forum and conversation with people like the engineer you mentioned before, Misty. Like people who are writing new things in COBOL.
Misty: Yeah.
Marianne: I find that fascinating. I would really love to know like what is it the thing that they built? Like why is COBOL the right language for it, and what has been their experience? What’s their maintenance strategy over time, right? Because I know that they’re out there and I know that it’s more than like, little toy or joke projects. I also know that there’s like a web framework for COBOL, but I think that’s mainly meant as like a joke, right? So it would be interesting to sort of hear the perspective from people who are not maintaining old stuff in COBOL, but writing new stuff in COBOL for future reference.
Misty: I’m going to pause one second because I forgot to bring my mic. Can you hear me fine?
Marianne: Yes, yeah.
Susan: Yeah.
Misty: Oh well, let me just grab it just in case. I am a mess. I’m sorry about that. All right so I haven’t seen a lot of new development and I’m wondering. I’ve never ever asked anyone this question before, but I think you ladies are the right people to ask. Clearly there’s bias. COBOL isn’t even on the list when they’re trying to figure out what language to write a new application in, so we know that that bias is there. If we could wave a magic wand and that bias disappeared, what are those use cases where you think COBOL would be the right programming language for brand new development?
Marianne: I look at it for anything that involves bulk transaction. That’s what it was developed for and that’s clearly where core competency of it still lies.
Misty: Bulk transactions. That’s really interesting because I had somebody once theorize that the financial calculations underneath cryptocurrency would be an interesting use case. What do you think about that one?
Marianne: I don’t know, but that would be amazing to watch. I have so many opinions about what’s going on in the cryptocurrency space—
Misty: That’s not this webinar.
Susan: Yeah, really. This is not the right forum for all my opinions about like “Cryptocurrency: Snake oil or Savior?” but I mean like this space is really interesting from sort of a technical point of view, and something like that would be a really incredibly insightful conversation, I think. I doubt it would catch on because the Venn diagram of people who are interested in COBOL and like this type of—
Marianne: Old currency interlock. Yeah.
Susan: Yeah, there’s very little space between those two.
Misty: Ah yeah, yeah. There is very little space, but you never know where the future is going, because things like this—
Marianne: We will find someone on the internet that likes that and that’s it.
Susan: If it makes them money or saves them money, if that calculation that goes out to eight digits, you know maybe this will catch them. They’ll say hey.
Misty: Spoken like a fantastic salesperson. So if we can show how it makes them money, they will be interested.
Susan: Right, absolutely.
Marianne: It would be very interesting to sort of get a sense of what is the amount of COBOL that’s not on a mainframe and is also not an intermediate step in getting rid of the COBOL entirely. I’ve seen a bunch of COBOL on mainframes. I’ve seen a bunch of COBOL in the cloud, usually running on an emulator of a mainframe preparing to like, get to a different future state. I don’t know that I’ve seen a great amount of COBOL running in like, a cloud environment or even like a local personal computer style application, just for being COBOL, right?
Misty: Susan, you have a perspective on that.
Susan: I don’t have percentages. That’s a great question. I should probably know the answer too, but I would still assume the majority of COBOL is sitting in a mainframe or in a cloud-based mainframe environment, right? But the customers I support are typically distributed COBOL environments and many of those applications were written prescriptively to be distributed. So we have over 350 software application providers that chose to write their application originally in COBOL, and they’re running it in Windows and Linux, and they always work. And when they sell a new end user their application, they’re selling more COBOL every time they do, so it is actually growing. I’m assuming not at the same rapid pace as maybe some of the larger financial processing environments are growing, but we see an awful lot of distributed COBOL, which is where Micro Focus plays. We aren’t typically on the mainframe, we are what happens when you come off the mainframe, so yup.
Misty: Yeah well, we did do a COBOL survey. We partnered with Vanson Bourne that did a COBOL survey and they did an estimate of how much COBOL is out there. They found 800 billion lines of code in production—
Susan: Yup.
Misty: It’s an estimate, right? It’s a range, but still. No matter how you look at it, that’s significantly more than the last time the survey was done, which I think is like ten years ago.
Susan: I remember 300 billion. I mean, so yeah.
Misty: On the last one, yeah. It’s a lot and the vast majority are planning to update those COBOL applications. I’m trying to see. There was a survey that said what platforms they’re on and it’s in the survey. There’s a webinar you can watch and you can see that if you’re really curious. I should have it memorized since it’s kind of my job, but I don’t remember.
Susan: And honestly going to the 80s and 90s, a lot of our commercial accounts wrote distributed COBOL applications and you might wonder why did they do that? Well, they had the skills in-house. They were replicating maybe an expensive centralized environment that they now needed to create smaller distributed versions of, so they went with what they knew. They went with skills in-house and basically an application structure they’d already done once before. So it’s sort of a roll it again process that built a lot of distributed applications that were written for distributed environments but maybe were mimicking the original, you know, 1.0 version of this application that still lives and breathes in the mainframe.
Misty: Yeah, I think there is still quite a bit out there that’s not on mainframes, and I know that moving these applications to cloud is accelerating. I saw a recent survey run by Accenture. It was stunning to me in February of 2021 they asked something like 100 large, really large banks what they planned to do with their mainframe applications. So that’s not necessarily COBOL, but probably a large share of it. And 42% said that they’re going to move more than half of them to the cloud within five years—excuse me. Just nine months later, that number went to 84%.
Susan: I was about to correct you because I was saying it’s not 42. It’s 80 so yes, yeah, I read that same—
Misty: In November it was 84%, and it’s like that is a massive turnaround in attitudes. My theory is—and there was an article that Forbes wrote about this result, and they conjecture that the reason for that change is that these large banks had already moved their, let’s say operations to the cloud or customer support, and they saw the advantages of it, and that convinced them that they should move everything else. My theory is that the pandemic really highlighted the costs of not modernizing those applications. I will say you can modernize COBOL in place on a mainframe, and I think there’s plenty of instances where that is appropriate and the best choice. But once you’re looking at modernizing it and by modernizing—I don’t mean using new technology, right? I mean Marianne’s definition, which we’ve talked about on other webinars over and over again, which is making sure the application is meeting your modern needs. So I can keep the modern in there. So she says returning to operational excellence, but regardless it’s about it doing what it needs to do.
Marianne: Right.
Misty: Once you open it up and you start to look at “what do I need to do to make this application meet my modern needs, do what it needs to do now?” all options are on the table. So turning it into microservices on your mainframe or moving to DevOps on your mainframe or moving it to cloud if that application needs very dynamic scale-out capabilities—that’s harder to deliver on the mainframe, then that’s the right choice for you. I think what is really going on right now is they realize the vulnerabilities that they had all along.
Susan: Do you think also, Misty, like, the pandemic de-risked it all? In other words, the art of the possible became the art of the reality where companies might have been hesitant to be the first ones to risk their mission-critical environments by doing something so dramatic as moving it to a cloud. The pandemic threw them in there and all of a sudden it seems “hey, not only is this not risky, it’s working and it’s saving me money and my goodness, why didn’t I do this sooner?”
Marianne: You know what? I didn’t think about that one, but that’s a really interesting point. It could be success breeds success, you know. You see failure after failure and you don’t want to follow that path, but when you start seeing success after success, which we’re seeing right now—
Susan: Right.
Misty: AG Insurance, I just said. Santander, Kmart—you know some really big organizations have moved their core services, exactly as it was on the mainframe, moving it onto the cloud, and they’ve been able to perform. Quantis—big, big companies are doing this in a lot of different industries and maybe that’s what accelerating this. It’s interesting. Yeah, so Marianne, we’re conjecturing and I know that’s one of the things you love to do. Do you have any theories?
Marianne: The thing I keep coming back to is that a lot of time you can have a system that is fundamentally broken but doesn’t appear that way, because within the boundaries of what you’re asking it to do, it does the right thing all the time. But when you change the context—like now requiring everyone to work remotely from home because they can’t come into the office—then suddenly it’s incapable of adapting, and it starts to very quickly break down when people try to do the same functions that they had. So it’s not a huge surprise to me that the theory that you’re putting out there, that perhaps the pandemic accelerated some of these projects and the trends towards moving in these directions. Because the pandemic actually accelerated a lot of things that business was sort of digging their feet in like the—I have been running distributed teams for like years and years before and it became a thing. I then had to teach my colleagues how to do. They were actually quite surprised that there was entirely based on how you successfully run a distributed team and like not go crazy, right? Because everything that they did in terms of the hiring they had to do and the way they had to manage their business was working. It was working fine so why change, right? Then suddenly it wasn’t working fine and they have to change. So I think it’s probably a similar dynamic where a lot of companies were sort of just happy with the way things were going with their data centers and maybe you know, their mainframes, and then suddenly when they had to sort of completely change the way they operated, they started to see some of the maintenance costs that they had accrued by ignoring it and just assuming that it worked. That helped reprioritize everything.
Misty: Yeah. I’m loving this conversation, by the way. I’m just going to take a moment to appreciate the two of you because you know I’m in this space all right all day, pretty much every day of the week right? And even when I’m not working, I’m still reading about COBOL and mainframes. Both of you keep bringing up points I hadn’t thought of or read before. We’re inventing new space here, and the whole point of Women of COBOL is to highlight you for what you know. You’re proving the point the right now. You guys rock. That’s all I wanted to say. I love you both.
Marianne: Thank you. Thank you, Misty, and I’ll just say, having lived in the world of COBOL for many years, I don’t tend to get that sort of accolade [laughs]. I’ve seen people spit out Starbuck’s Coffee when I tell them what I do for a living, so I really appreciate it.
Misty: You know Marianne, you have something in your book that I have referred over and over again, and that is a little bit of history of programming languages, and how there’s the three different paths, and why these more complex languages tend to be more popular. It was so fascinating to me. Do you want to explain a little bit of that?
Marianne: Yeah, so basically what I believe about the growth of programming languages is that you can sort of sort them into family trees of lineages depending on how their target audience was. But when you look at things like COBOL and FORTRAN, they are very clearly geared towards the business user, right? It’s built—like the whole reason to exist, their mission statement from the very beginning was like, well let’s write a programming language that people who are not computer people can write code. FORTRAN, it was like math and sciences. And COBOL, it was business analysts. Open that up to the everyday enterprise and it’s users versus something like C, which was quite clearly—the audience was computer scientists who were interested in sort of the theoretical space around like hardware and software, and like the mathematical concept behind computation. It was written—like when you learn the language of the mathematics that they were thinking about, a lot of the syntax of these languages suddenly comes to life, right? It isn’t just like an arbitrary choice. It makes perfect sense and I think progressively you sort of see the languages kind of come into that kind of lineage. So the thing that I’ve always said is that it doesn’t really make a lot of sense to me why when people want to get rid of their COBOL, they immediately gravitate towards a language like Java. Because if you think about the languages that exist today and are popular, well supported and have lots of programmers working in them who are doing the sort of the things that COBOL traditionally does around data processing, the language that really is the heir apparent to a lot of the work that would have gone to COBOL is Python, right? Like when we talk about, we need to process a huge amount of data and do these kind of analysis and calculations, like most software engineers would reach immediately for Python, not Java. But the type of software engineer who maybe, like 30-40 years ago or even 20 years ago became a COBOL engineer is now becoming a Java engineer. So it’s really like it’s about that prove that perspective and that use case and the types of tools that you were exposed to. I find it really interesting how that influences what people are drawn to and what they identify as the correct solution, so I spent a little time sort of breaking that down in much more detail.
Misty: Yeah, that’s really interesting. I tried to convince my son, who’s a computer geek—he’s teaching himself programming. I tried to convince him to look at COBOL and his choice of programming language was 100% made by what his friends were learning.
Marianne: Sure.
Misty: So I think there’s a lot of social peer pressure and we fool ourselves into thinking that these choices are made logically and on a technical basis. But you know, especially after reading your book—everyone read her book—I came away with wow, I never realized how much of our business decisions, our technical decisions are actually based on emotion, social pressures, history—
Marianne: What you know.
Misty: Yeah.
Susan: Yeah, you’re going to apply the tool you know. I’m kind of curious, having heard your thoughts on the providence of these languages, where they came from and you know COBOL being a business language and FORTRAN being a math and engineering language, etc. How would you define a modern language? What in your mind makes something a modern language?
Misty: Oh.
Marianne: Well so that’s a thing—I’m usually on the other side of that question, right? Because the scenario that I find often and is the most entertaining for me is, you know now Java is considered an old language. It’s a legacy language. Get rid of that old Java and move on to Python, right? And that’s generally—
Susan: We can write that in COBOL for you, don’t worry.
Marianne: So yeah and that’s funny because if you actually look at the timeline of those two languages, Java and Python, Python is older than Java. But most people are surprised by that fact, right? Because the perception of these languages is Python is modern, Java is old and enterprise-y, and a lot of it goes back to what we were saying before. The people who work in those kind of languages and the situations that we associate with those kind of languages, and since Python has made such huge inroads in data science and AI and machine learning, people naturally associate it with like more cutting edge. If I had to define what a modern software language is, I’d probably look at what the trends are in the research. Like right now, what’s going on in the programming language community is a lot around typing. It’s a lot around formal reasoning and so the kind of languages—I don’t know that I would describe a language as particularly modern versus other, but if you put a gun to my head and said like you must pick a modern language, I would look at things like Haskell, like Elixir, like things that are trying to leverage a lot of this return to Boolean logic and formal methods and verification within the language itself. Maybe even like if you wanted to go for a list, maybe even looking into like the closure world and things like that. And so that’s really what I would, if I had to make a definition for it, I would make it about how these concepts that we’re seeing in research papers [that] are starting to come and be embraced as first class citizens within those languages.
Susan: I’d call that postmodern [laughs].
Marianne: I mean some of this stuff is more like abstract expressionist language—
Susan: Yes.
Marianne: Like I’ve stared at some like TEAL A+ until my eyes bleed, and I’m still not really sure what all the symbols mean in a row. So yeah, I mean a postmodern language might be that.
Susan: I mean it’s somewhat of a loaded question on my part because when I hear customers worry about COBOL and COBOL is old and we’ve got to get rid of COBOL, I try to redefine what’s modern as what’s running, what’s working.
Misty: Yup.
Susan: Your hammer might be the oldest tool in your toolbox, but it works really well for certain things, right? You’re not going to use it for every job that you’ve got, but if it’s working and it’s interrelating with the other things around it in a way that supports your future modernization needs, it’s modern. That’s the structure I would think about. What’s lifting the workload for you? What’s helping you? What’s bringing you reductions in costs? Those things are modern.
Marianne: I think that’s a great point. Nobody ever complains that their hair dryer isn’t modern enough, right? Does it work or doesn’t it work? I think a lot of that has to do with the fact that people are really used to computers breaking.
Susan: Right.
Marianne: They’re really used to their software not working, and so the oldness of or newness of the software gives them a feeling of implicit security in an inherent, uncertain space. If software were more reliable, no one would care how old it was, right?
Susan: Right, agreed.
Misty: So all right. I’m looking at the clock here and I want to make sure that we end on a fun note, so I have a crazy idea. I should have warned you in advance, but I believe you guys are going to be able to hang with me. You guys both have so much experience, just so much. I’m sure you have some amazing stories that if I sat down in a bar with you after a conference, you would blow my mind with some crazy, crazy stories with the names removed—
Marianne: Sorry. They’re all classified.
Misty: No. Tell a crazy story that would blow the minds of our audience. Anybody got one?
Susan: I mean, I’m in sales, Misty. Do you want a crazy sales story?
Misty: Sure. Something about COBOL, attitudes about COBOL, failed projects, successful projects only because somebody rode their bicycle in the middle of the night still in their pajamas. I don’t know. Something.
Susan: I mean I’ll tell a story that’s kind of an embarrassing personal one that I haven’t told anybody really.
Misty: Oh yes! Oh, I’m loving it.
Susan: Back in the day when I was six months pregnant and I was calling on a large financial institution in the World Trade Towers, and I had finally lined up a development team of about 60 primarily men to hear our pitch about analysis tools. It was a product called Revolve and we were selling into their shop so that they could better understand their application landscape, application environment, how it maps, dependencies, all that stuff. And we finally got the room together. I decided that day to put on a nice red yoke sweater with a black body to it and I paired it with some black slacks. We got in front of this whole group and we made the pitch of the century. It was great. There was so much to know. We showed them their own software applications running within our tool and how it did things and all this. At the very end, the big guy in the back of the room, the boss of all the teams, does this and he says “live long and prosper.” I looked down at my outfit and I’m literally dressed like a Star Trek character [laughs]. Oh my God, that was the end of sale. They didn’t buy it. They probably could have benefited from it. They are no longer in business.
Misty: That’s a good moral of the story. Don’t make fun of a woman’s outfit. Thank you for recognizing the Star Wars reference, dude, and you might to take care of your COBOL. Otherwise, you’re not going to be financially stable.
Susan: You can cut that whole story out if it’s not appropriate, but it cracked me up at the time and yeah.
Misty: I think it’s great. I think it’s great. Do you have a story for us, Marianne?
Marianne: So my story is not my story. It actually comes from my little brother, who was in the Navy for a number of years as a nuclear engineer. So therefore it’s not about COBOL, because I do not believe there are any submarines that are currently running on COBOL. But he was telling this story about how they had this one particular valve that kept breaking on the submarine. They would replace it, and it would be good for a couple of days. It would break again and they’d replace it again. It’d be good for a couple days, and it would break again. So finally, one day it was like chicken finger/chicken wing night at the mess hall, so they took the bones from the chicken wings and they built kind of this like voodoo doll and put it next to the valve, and then it didn’t break anymore after that. They were like, oh cool. So they’re like, this is great. They’re going about their day. Like a week or two later a junior officer comes in, looks at the space and goes “what is all this garbage?” There’s like literally chicken bones just hanging around. “Get rid of all of that. Clean up this place. This is unacceptable,” right? And so these very diligent Navy men, they’re like “yes sir,” and they go and they clean up the space and they throw out the chicken bones. The next day the valve breaks and so the commanding officer comes in and he says, “I thought we had this licked. What’s going on?” They explained, “well we built this thing out of chicken bones and we put it there and the valve stopped breaking. Then the junior officer made us get rid of it and then the valve broke again.” The commanding officer stares at them for a minute and goes “well put back the chicken bones then!” [Laughs] The moral of the story is trust the process that works. Don’t overthink it.
Misty: Don’t overthink it. I think that’s probably —you know what? It’s not a COBOL story, but in some ways it is, right? Because the COBOL works and why are we over-engineering things, right?
Marianne: Right.
Misty: You might end up breaking it. Well, boy this was fun. Any parting words for our participants, people that watching Women of COBOL here? No?
Susan: What would I say? I would say there’s opportunity, and this is an expanding space. Be excited. You know what we thought was going to be sort of the sunset of an environment that many people have built 40-year careers on is launching into a whole other realm. It’s going to the cloud and that brings on a whole lot of different needs from the technologists that support this. So I would just be very encouraged that if you’re building a career in this space, consider security. Consider knowing your languages that wrap around legacy. Become a legacy modernist. Figure out ways that you can use the skills you brought with you to support companies that are still running legacy system. I think you’re going to find a lot of opportunity.
Misty: I think you’re right on that.
Marianne: I’d agree with that point. I’d say I’ve never gone wrong by just pursuing things that were interesting to me. I think trying to engineer your career for some sort of long-lasting impact based on what other people think good technology is isn’t the way to go. You’ve got to optimize for your learning and your engagement with the technology.
Misty: I love that we ended on some career advice, so I’ll throw in mine that’s related to what you’re both saying. And that is the most valuable people in any company are the ones that not only understand their little piece, but they understand how their piece connects to the things near it and related. So I never told students to be a COBOL programmer. I tell them to add it to their quiver so that they can bridge the old and the new and be that person in the company that can bring things together and help them figure out how to go forward. Great. I love this ending. Fun stories, great advice. Thank you so much for your time today. I love to talking to both of you, so it was really exciting to talk for me to talk to two of my favorite women at once. Thank you very much and I hope the audience had as much fun as I did.
Susan: Good stuff. Thank you both.
Marianne: Bye.