Phil Teplitzky on Structured Programming and Software
Reg Harbeck: Hi, this is Reg Harbeck and today I'm here with Phil Teplitzky, who is the managing director of the Teplitzky Associates, but that doesn't tell you nearly as much as you're going to find out about someone has been right there in the middle of the history of the mainframe in so many interesting ways. Phil, tell us. How did you end up on the mainframe?
Phil Teplitzky: Well, it's interesting. I got a graduate degree in computer science back in 1976 and there were only mainframes in 1976. My degree specialty was structured programming and design, so I actually was one of the earliest adopters of building quality systems based on software metrics with a subspecialty in problem solving and general systems theory. So, my first job out of graduate school was on a mainframe, of course, and I was one of those people that you hear about in legend that started punching cards. I punched cards and had hanging chads before anyone had heard of it. [Laughter]
Reg: A Florida connection right from the beginning although, of course, you're not actually based in Florida. Now you've been mostly around the eastern United States for your career?
Phil: I've been my entire career in the New York City area.
Reg: Wow, okay.
Phil: Just to give you the perspective where I went from a graduate degree in the mid 70's. I have over my career been a CIO, a CTO, a senior executive at Citibank dealing with the data architecture of the retail bank, US and Europe. I've been the managing director at several consulting firms including three of the big eight firms over the years starting at the lowest at Peat, Marwick, Mitchell, and winding up as a national director over at Coopers & Lybrand.
Reg: Cool. So now I'm going to guess that even though you took such advanced education about what might be construed as the technical side of things that you found yourself pretty early on in the strategic side of things. How much opportunity did you get to actually doing any programming before you started getting pulled into the strategic side?
Phil: Not… two—three years’ worth, but I did in graduate school write some utilities that I think are still running on IBM mainframes.
Reg: Oh cool.
Phil: One was the condensed listings program, which if those of you that know green bar printing and programs, you to get the code and the cross references and then the errors. We wrote a program that took that and put it all on one page. On the left was the cross-reference; on the right was the code and on the bottom were the errors. That's been still running for many, many years so having been taking my degree in the hometown of IBM, Endicott New York, at SUNY Binghamton, mainframes and dealing with the people who actually wrote the code, meaning the operating system. They were in my graduate school class, so I knew not just what people do, I knew the people that were making the magic behind the scenes.
Reg: Cool. Now of course by the time you got your degree, OS/360 had been GA for nearly a decade, so you got to meet people who were basically moving the ball forward as it were based on that initial effort that of course Dr. Fred Brooks wrote about in The Mythical Man-Month. What were some of your impressions about the journey that OS/360 and its successors has had at that point?
Phil: Well, I actually met Fred once.
Reg: Oh neat.
Phil: My senior advising professors, Gerry Weinberg and Don Gause, were two of the founders of structured designed and programming. My class was one of the first to learn that, so I was one of those programmers, if you can believe it, who never wrote spaghetti code, never learned how to do it, learned how to do it from requirements forward, learnt the discipline of walkthroughs when it was still in its infancy. I actually even met Grace Hopper a few times.
Reg: Oh wow.
Phil: Of course, you can't—because in those days it was Endicott, it was IBM; it was the hometown of OS/360. She would come and lecture, so I met her. She came and gave a lecture at school. So not only did I get the chance to learn it as it was changing in to the structured design and programming where do it right the first time and if it doesn't work by the third time do it over, but in my class we had the folks that were writing OS/360 and as we were using the features, we could go to the guy and say “So, why did you write it this way?”
Reg: Neat.
Phil: It was an interesting way to learn.
Reg: So, I'm going to guess you wrote a fair amount of Assembler.
Phil: No, no. We actually were being trained to be—how should I say it—senior level managers. We learned high level third generation languages. Yes, I had enough Assembler and JCL, so I could make the world work, but we were really being trained to be the next leaders and almost everyone from my graduate class wound up becoming chief technical officer, head of disk development at DEC, head of OS at DEC. One of them wrote the—For Lotus and Manzi wrote all of the printer interfaces, so we were being trained—we were the first generation of people being trained not to be computer scientists in the lab, not to be programmers, but be the people that ran the next generations of development and built the big systems, the major systems. It was a different kind of training. We got a lot of training in problem solving. The book, which I recommend to everyone to read, Are Your Lights On? by Gerry Weinberg and Don Gause, brilliant book. Everyone, no matter if you're a computer scientist or you're a social worker, I recommend reading the book. It is one of the seminal books on problem solving.
Reg: Cool.
Phil: So, we spent a lot of time on problem solving requirements, translating requirements into design and we learned programming as being coding and I'm going to make this point because it's tremendously important. You get the requirements, but you also get the constraints. The point of design is to take the requirements — what it should do –, the constraints of what it shouldn't do, and design the program. So, we learnt design first, pseudo code, structured charts, flow charts, whatever diagram, Nassi–Shneiderman charts, and the act of programming should be the act of coding, the translation of a design into a target language. It is not the place where you do design.
Reg: Now that said, you haven't mentioned which language it was yet, and I keep trying to decide whether it was PL/I or PL/S or PL/X or COBOL or—?
Phil: The ones I learnt on were APL—
Reg: Oh.
Phil: An interpretive language and where everyone always talks about Ken Iverson teaching APL because he decided he was the inventor. I actually was taught by Iverson's manager.
Reg: Oh wow.
Phil: Mr. Rose—so I learned from Iverson's manager how to do APL because it was interpretative and it had if you can believe it many, many of the features that now became Excel because it—
Reg: Oh.
Phil: Had some very sum reduction, which is just adding up of the column, matrix algebra in it so we used a lot of the things that now became visualization statistical analysis. The other one is PL/I and the reason for PL/I is—it's basically COBOL or ALGOL on steroids, but it didn't matter because I didn't learn the language.
Reg: Oh.
Phil: I learned the BNF. We learnt a language from the BNF up.
Reg: Backus-Naur Form, right?
Phil: Yes, poor Mr. Naur has now been out of it. They call it Backus Normal Form now.
Reg: Oh geez.
Phil: But I learnt it by learning the language, so from the abstraction to the concrete. The result was when I went out and got my first job and I went to a different language entirely on an HP-Hewlett Packard machine, I designed a program my manager gave me. He thought it would take me six months to a year to learn it. I did it in less than three weeks.
Reg: Nice.
Phil: He said how did you do this? I said because I designed in the abstract and it was a matter of only finding out how this specific language did that specific command, so I went to the back of the book and read the BNF.
Reg: Very nice.
Phil: So, if you learn programming the right way, which is from the abstraction learning what a language is, what BNF is, not COBOL or PL/I or ALGOL or C or whatever-Java, all of them are written in BNF. If you do your design in the abstract to go to any particular language is knowing how to read the BNF.
Reg: So, my sense is—sorry didn't mean to interrupt. Go ahead.
Phil: That's why we teach programming wrong. We shouldn't teach the language. We should teach first what the language is and the abstraction of what BNF is and then you can learn any language because now you have the tools to learn.
Reg: Including COBOL.
Phil: Including COBOL because it's always—
Reg: I'm going to guess that your approach to how we fill a new generation on the COBOL workforce is probably geared a bit differently from what people might be defaulting into.
Phil: Yes. I actually have written—I think I've sent it to you-a 60—70-page curricula for doing a COBOL work—boot camp and what it does is combine software engineering, so you understand what a program is and how they work and how data structures plus algorithms equal programs. You understand how the Von Neumann machine works and you learn BNF, and you learn the language, and this is a very, very important part: You learn the process of building software. You understand the translation of requirements into software, how to test software, and the systems development lifecycle because the systems development lifecycle is a very complex interconnected system. I've written a couple of paper on this. There are about 17 or 18 different life cycles that interact with each other to make software work and I've taken this from the bottom and as the CIO and CTO having responsibility and shown how they interact not as a zero one interaction each step, but that it's a fuzzy set relationship that's dependent upon the type of software and type of organization, type of tools in the environment you're working with, so a visualization using a tool is one thing. Writing E911 for a big city where you need uptime of 0.000001 which one minute a year is quite different. So, those are the different things you have to balance.
Reg: Yeah, I have a feeling that you and I could continue this conversation for about 30 years and not run out of stuff and so I feel guilty kind of fast forwarding, but I don't feel like I have an opportunity to do otherwise just because there's so much to learn about your journey. But what I'd like to do now is jump into something you and I both are working on and that is the COBOL working group. You've contributed a lot to that and the whole idea of helping the world reawaken to the prevalence of COBOL and the need to recognize it and responsibly plan for the future in a whole bunch of different ways with that fact including the survey we recently did. Maybe you could give some impression of what led you to the point of being involved in this and you know how do you see the outcome and your participation in it?
Phil: Well, interesting enough, having been the head data architect for Citibank, I was tasked with developing a model for online banking. This is 25 years ago, like, a long time ago and one of the factors we faced was that the core banking systems are COBOL. They run on big mainframes and there—and in fact one of the realizations we came to is that there is a class of applications; those that have to run within a constrained time window, what we used to call in the old days “the batch window”, that need to have very large volumes of data come in from other systems, have to run on a mainframe in a third-generation compiled language. There's just a whole class of programs that must run that way. You couldn't possibly run them, and I know everyone is going to say well look at Amazon. Well, Amazon—what you think of Amazon being the online order is not really very processing demanding because it operates in human time, so you sit there for a half an hour and do your order, you hit the enter key and it keeps a record of what you've ordered. Then when you've finished, you go and do your credit card, which is done in Assembler to a mainframe over at MasterCard or Visa and gets recorded in the bank to do the money transfer on a mainframe at night in the batch window and takes the money you know, and it credits and debits your accounts.
Reg: That's such a fun perspective on Amazon. When you're using Amazon, they may not be using a mainframe, but you're using a mainframe for the most important backend stuff they're relying on.
Phil: And that even gets more interesting because when they finally do the order and send it to the warehouse to figure out how to do the picking and everything else, they're running a mainframe to do the order entry, the picking, to keep their records because how else can you run a million square foot warehouse so what do you do? You do the same thing that GM has done and Ford for the last 40 years. You need a large mainframe to do the optimization because you would need a room full of computer so when they sell you the Cloud in their businesses, that's a way of optimizing for people that need little spaces. I know people say well I run big. No, you don't run big things on Clouds. You run big things on Clouds of mainframes. If you must be up, you have two mainframes sitting there connected by a long wire so if you lose one datacenter, you have another. This is not for the guys running Quicken, you know, on his—for his small business and by small I mean anything under a billion dollars. I'm talking if you're GM and you got to run the assembly line, you have a big mainframe. This is the class of system we're talking about.
Reg: Now you mentioned something about Amazon and a mainframe, and I want to a connection. You're not saying Amazon actually has IBM mainframes on premises right?
Phil: No, no. We're talking about how do you run when you're going to go to UPS—
Reg: Got it.
Phil: And there at the factory, how do you optimize talking between them? How does Amazon do wire transfers and Fedwire to their suppliers: I mean there is a certain class where you got to run a swift transaction to the guy in India who's supplying you, so there's a whole lot of—when you think of Amazon, it's monolithic. People say well I'm going online, I'm buying their Cloud, but there's a business called Amazon and they've got to run payroll for 100,000 people. What do you run a 100,000 people payroll on? Now you may go to a service but they're running it on a mainframe.
Reg: Cool so something like ADP for example.
Phil: Yeah, because that's—
Reg: Who have a mainframe.
Phil: There are a certain class of things that have to have it. If you're writing a program that has to take all the Fedwire, Swift, chips, transactions and you have 4 hours to process them because by law you have to do the credits before the debits to get your actual bank balance. There’s nothing else in the world up to it.
Reg: Cool.
Phil: You can't take a big VSAM file and process it.
Reg: Well I normally, at this point, I say, “So let's tell us some closing thoughts on the future”, but I don't want this to be simply closing thoughts because I think you've got a vision of the future built on all this time in the strategizing and everything that is somewhat more comprehensive, so maybe if you can just kind of describe the future not merely as you predict it, but as you—I like to say prodicted, as you would involve yourself in making to the extent that you could be involved in seeing the future of IT, of COBOL, of large enterprise computing.
Phil: I think it's going to be the hybrid approach. You're going to have the core systems, the ones that must process in a limited time in a scheduled type of environment because there are certain cut-offs in business and that will be wrapped with core—with how should I say—front ends and back ends that will give end users capability, so you'll still have the web. You'll have the equivalent of interactive, but when you hit the enter key for the final cart to be processed, it will go back to a core system. It's like I don't know online banking. Online banking the balance you see while reflects what it is isn't the legal books of the bank. Legal books can only be done after you process the credits which come in at night from Fedwire and chips. Now, for the average person, it doesn't really matter, but there is a sense of the legal books versus the shadow—most of what's really happening. They developed this with cards. You know, where do you get payments and the card transactions? Having the assurance that, if you're in the United States, and a transaction comes through from New York, where I live, and my card is processed in Japan at the Olympics, something's wrong and only a big mainframe can deal with that kind of multiprocessing in real time. So, what you'll have is the hybrid environment. What we don't have is someone to replace the programmers who are reaching their 50's and 60's who built this stuff, and schools aren't teaching it anymore. We're going to have a shortage of folks who know how to do structured design, programming, mainframe programming, COBOL to maintain doing this. They've tried outsourcing it to India, to Russia, to Poland and the problem becomes it's a huge security risk. This is the jewels that keep the country running. There have been some estimates that COBOL code represents the second most valuable asset in the United States after oil.
Reg: Wow. After which?
Phil: Oil.
Reg: Oil, wow.
Phil: Oil and gas.
Reg: And of course, once we're all running solar and wind power sometimes in the next few centuries, maybe we'll still have COBOL.
Phil: We'll still have COBOL. You'll have COBOL or whatever the analog is that's a compiled program because compile is much, much faster than interpretative no matter what you do just by definition, and it's much more secure. It's got more resiliency and when you use it with modern databases, you're going to have to have a mainframe. At the end of the day if you're running a database that's 25 TB, where are you going to run it? Now I've built some 25 TB databases in my day. You can only run them on a mainframe, maybe on a parallel nothing nothing machine, but it's still the equivalent of a big mainframe. Quite frankly OS/360 or whatever they call it now O/z is a much more reliable OS, much more resilient and doing an LPAR is a lot easier than figuring out how many extra Intel processors you have to put on.
Reg: That's just putting it lightly yeah. So, I guess before saying goodbye, I just wanted to see if there are any lost thoughts you wanted to share with everybody. Obviously this has been barely an appetizer of everything you could share, and people probably should Google you up and see what else you've been writing and doing, but any final thoughts?
Phil: Yes. Being as we lose the blue-collar jobs, there is an opening for smart dedicated people to make good livings being mainframe COBOL programmers. It is an open field. Not everyone has the graphic ability to be a web designer, not everyone has the backend analytic skills or the background in statistics to be a back-end analytics person, but most people who have gone through college and have a reasonable familiarity with computers and some mathematical or logical background can make very good mainframe programmers and pretty soon we're going to have a shortage of those. I think the COVID-19, with the changes in benefits prove that, and my experience having dealt with this for 45 years we're going to need them. This is a good job opportunity.
Reg: Cool. Well thank you very much Phil. This has been fascinating.
Phil: My pleasure. Anyone wants to talk about it, get in touch with Reg because as Reg said we work on the committee together, meet on a regular basis, more than happy, have big file cabinets full of stuff and as I said I had an education business where I know how to teach. I have a graduate degree in teaching as well. If I can teach high school student social studies, I can teach you COBOL.
Reg: Awesome. So, I'll be back with another podcast next month, but in the meantime, check out the other content on TechChannel. You can also subscribe to their weekly newsletters, webinars, e-books, solutions directory and more on the subscription page. I'm Reg Harbeck.