Show notes
https://media.blubrry.com/thewomenintechshow/wintshow.files.wordpress.com/2020/06/s1e1-rebecca-parsons.mp3 Subscribe: Apple Podcasts | Spotify | Android Rebecca Parsons has been working in technology for over 30 years. Throughout her career, some of the things she’s worked on are system architectures, software design patterns, distributed systems and best practices. Having started programming at 13 years old, she has seen significant technological transformations. In this episode we talked about the evolution of technology and how that leads to changes in how we develop software. Rebecca is currently the CTO of ThoughtWorks. In 2018 she was the recipient of the Technical Leadership Abie Award. Abie Awards are presented by AnitaB.org, a global nonprofit with a goal of reaching 50/50 gender equity in tech by 2025. Abie awards honor and celebrate women who have led technical innovations and made a notable impact on business or society through technology. This episode is part of a series of shows that highlight the work of previous Abie Award Winners. For more information about the Abie Awards, go to anitab.org Rebecca Parsons, CTO of ThoughtWorks Transcript [00:00:12] ES: I’m Edaena Salinas, Software Engineer and host of The Women in Tech Show, a podcast about what we work on, not what it feels like to be a woman in tech, for more information about the show, go to wit.fm Rebecca Parsons has been working in technology for over 30 years. Throughout her career, some of the things she’s worked on are system architectures, software design patterns, distributed systems and best practices. Having started programming at 13 years old, she has seen significant technological transformations. In this episode we talked about the evolution of technology and how that leads to changes in how we develop software. Rebecca is currently the CTO of ThoughtWorks. In 2018 she was the recipient of the Technical Leadership Abie Award. Abie Awards are presented by AnitaB.org, a global nonprofit with a goal of reaching 50/50 gender equity in tech by 2025. Abie awards honor and celebrate women who have led technical innovations and made a notable impact on business or society through technology. This episode is part of a series of shows that highlight the work of previous Abie Award Winners. Before we move on with the interview. I’m really excited to announce that season 1 of the 5 Minute Mentor podcast is available. This is a podcast where you’ll get advice from prominent people in tech, authors, journalists, artists and more. For more information about the show, go to mentors.fm. Thank you. [00:01:47] ES: Rebecca Parsons, welcome to The Women in Tech Show. [00:01:51] RP: Thank you for having me. [00:01:52] ES: You started coding at 13 years old. Can you talk about your introduction to coding? [00:01:58] RP: I was at an algebra class, and we had just switched school districts, and there was some uncertainty about whether the grades I’d gotten in math, in my old school district, were actually relevant or not. If you will. And so I had actually learned all of the things my freshman algebra teacher was trying to teach me, back actually in the 5th grade. And so he realized that very quickly and at the time he was taking a course at the local University in programming and PL/1, and so he bought another copy of the textbook and he gave it to me and said “I will run your programs for you”, for whatever reason, and I never have learned why, but our school had a keypunch machine, and so he gave me a key to the keypunch room. So I just started working my way through the book and he ran my programs for me at the University when he ran his. And that’s how I learned to program, and I just,I fell in love with it. I thought it was fantastic. [00:02:58] ES: And, what time was this, roughly? [00:03:00] RP: Early to mid 70s [00:03:03] ES: OK. And you’re highlighting a lot that he was running your programs for you because you couldn’t do it yourself, right? It was more about you program, and then you take the program to the machine, right? [00:03:12] RP: Exactly. It was done on punch cards so it had to be taken to the University and the operator had to feed the cards into the mainframe computer at the University and it would generate a print out. So it was a very very slow feedback loop. [00:03:26] ES: And throughout your career you’ve tried new things and even helped define and adopt new approaches to problems. One of the examples that I saw is your work in evolutionary architecture. But before we dive into what that is, we need to understand how we got there by looking at how technology has evolved and how it has changed software architecture. So I want to begin with a quote that I’ve heard you say multiple times from Ralph Johnson, a computer scientist, and he said “Software Architecture is about the important stuff. Whatever that is.” Can you explain what this means? [00:04:05] RP: Well, when you look at different kinds of organizations, there are going to be different aspects of architecture that are more or less important for the success of that particular organization or for the success of that particular computer system within that organization. And one of the examples that I like to use, of around the year 2000 I worked on a trading system. And when people hear trading system they think high throughput, low latency, everything’s gotta move fast, performance is critical. But this particular trading system at that organization in their wildest dreams, they figured they might do 100, perhaps 200 transactions in a day, not in a minute, not in a second. In a day, but each transaction was worth billions and billions of dollars, and that was in the year 2000. Now, if I would have looked at that trading system and built it in a way that corresponded to the normal architectural characteristics of a quote, unquote typical trading system, well, it wouldn’t have been right. Similarly, there are systems out there where security of particular kinds of information just isn’t that important. But on the other hand, if it’s a medical record system, if it’s something that’s holding personally identifiable information or your financial data. Security is a huge component of it. So what this is basically saying is, your architecture needs to take into account what are the architectural characteristics that most determine success. And some of the other ones, you can just ignore because they’re just not that important. [00:05:54] ES: Got it. I want to understand now, how we got to a point where we’re using and talking about evolutionary architectures. In your 2018 keynote at Grace Hopper Celebration, you mentioned that when you were just starting out you had mainframe computers and no databases and that things were very simple back then. What did architecture mean for systems during this time. [00:06:21] RP: Well people rarely talked about architecture because there was a dominant model, what I described, mainframes, and they had file systems then. They didn’t even have what we would consider a database today. And so there just weren’t that many choices even at that time though, you did have systems save from Digital Equipment Corporation, the mini computer, and so you did have slightly different architectures. But if you looked at it from either the hardware perspective or really the software perspective, time sharing systems were not that common, and the way people thought about programs, you know they were, everything really was a monolith back then, and so software architecture, hardware architecture, none of those things, you just didn’t have that many degrees of freedom, and so you didn’t have that many choices to make. And in fact, when I went to Graduate School, even when you said computer architecture, what that meant really was the architecture of the chip, how computers were physically put together. People really didn’t talk about architecture in relation to software or the way systems you know code communicated with each other. That just wasn’t as big of an issue at that time. Just, as I said, because there were so few choices that it wasn’t necessarily an interesting discipline to talk about. [00:07:42] ES: So after mainframes, like you’re mentioning, there were, you know very few paradigms, and people weren’t really thinking about it in terms of silver architecture. What came right after mainframes when we started to think more about this software component and software architecture? [00:08:00] RP: Well, I would say the big shift really happened with client server, which was roughly in the 90s. Even before then, you did still have distributed applications you did have. You were starting to see more interesting networking going on. People were starting to use different networking protocols to allow different types of computers to talk to each other, but I think from a software architecture perspective the real revolution came with client server when you had the client PCs. I’m talking to the big back-end server and that’s when people really started thinking about OK, what processing should go where in these business applications and one of the things that is really still true today, although the difference is shrinking, is really the disconnect between scientific computing and business computing an in business computing, say in the 80s, people were looking at the large relational databases. How do I solve problems like that? The scientific community was looking at protein folding to do more what they called rational drug design, and trying to design new drugs to solve problems. Climate modeling, reservoir modeling was happening in the oil and gas industry when they were trying to figure out how to get more resources out of a particular well. And so really, during that time you had people thinking about scientific computing, which in many ways was more architecturally complex. And then you had more business computing, which the big revolution. As I said, was the advent of client server. And when on the business computing side, we started thinking more and more about what kinds of things could run on a PC. What kinds of things? How should we think more about the interaction between the user and the computer program? We got much more flexible user interfaces during that time, and so that was really the next big shift if you will, from a software architecture perspective. [00:10:02] ES: And would these shifts go hand in hand with changes in the hardware and the equipment from the time, would you say? [00:10:10] RP: Well, it was really enabled by the personal computer, because before then, the devices most people used to interact with the computer was basically just a normal terminal. We used to call them green screens, although not all of them even more green in their print, but we call them green screens. Even at that time, you know, there were still these complex graphics workstations use for things like chip design, and things of that nature. But primarily, if people were accessing a computer, they were accessing it through one of these very simple green screens. Once the PC came along, you had much more power on the interface device. And so you could make forms and you could do interactions and display information in ways that you really couldn’t do before. I mean, there was actually something called ASCII art. People would draw pictures with the kinds of characters that you would put on a screen because you didn’t have the ability to display things in anything close to a photorealistic way. But once we got personal computers, you could start doing more with graphs and all of that. [00:11:22] ES: In other talks that you’ve given around this topic for you mentioned, that there was a time when we were just trying to plan ahead and even try to think of, you know, architectures in terms of “would it still work in two years or five years?”. Can you talk about the way in which people were approaching software architecture during that period of, you know, planning a lot? [00:11:47] RP: Well, it really comes back to the pace of change of Business and Technology relative to the timescales, IT departments we’re looking at to create some software systems. And when you look at the early applications that people wrote on the systems, they were accounts payable systems or accounts receivable systems or a very simple address book. And there isn’t a whole lot in the world that’s going to change how accounting works, how you post to a general ledger, and, you know, dual entry bookkeeping and all of those things. The rules were very well understood and very stable and technology. While it was improving significantly, it wasn’t expanding the category of pieces of software that a traditional business would use. relational databases coming on the scene was a really big deal. But for a long period of time, in business computation, you had people running databases and people writing COBOL programs and the business requirements of those were relatively stable because they were addressing problems that really weren’t changing that much. When you look at both the software and the hardware stack these days, well, you have web frameworks, and you have graphics frameworks, and you have persistence frameworks, and you have different kinds of libraries for different protocols and different systems wanting to communicate and and XML parsing going on. And they’re all of these different pieces of these frameworks of our software stack. And those just continually change. And so, one of the standard lines when Neil and I give our joint talk on this, this is one of Neil’s lines, regardless of the audience, you know, I will bet you 100 in whatever the local currency is. So, $100, if we’re speaking in the US, if you can guarantee me what the name is of the JavaScript framework that you will be using in two years, and of course, everybody in the audience laughs. And, you know, the punch line, is that’s you can’t tell me because it probably hasn’t even been written yet. Well, back when I started, you might get a new release of the system software once a year or something, but you weren’t having the radical changes and the introduction of new capabilities. We didn’t have anything like Docker or Kubernetes, Mesos, any of those things, you know, and just the fallout in, you know, the container ecosystem and the container orchestration ecosystem, you know, things move quickly now. And so trying to say, I’m going to tell you, absolutely, what the technology stack is going to look like for an application I build in two years, well, that’s nonsensical. And yet, when I started, you could legitimately talk about a five year roadmap. And sometimes even a 10 year roadmap would at least be indicative. Those concepts when you’re talking now about technology, they make no sense and it’s because of the increased diversity of tools that we’re using the increasing complexity and capabilities that we have in our technology stack, and how rapidly they’re evolving. And, it also depends on the fact that we’re addressing problems now where the expectations of what the software will do, will change. Just think about how people’s expectations and how they’re going to communicate with their bank changed when people started using iPhones. Now, all of a sudden, they, all of these banks had to figure out a completely different way of dealing with our customers. And those kinds of changes are happening more and more rapidly. So business requirements are changing faster, and technology is changing faster. And with both of those, it simply makes that level of two and five year planning irrelevant. [00:15:46] ES: Got it, which is one of the core ideas behind evolutionary architecture right to be able to respond to changes like this like new tools, new platforms, new tech analogies, right? [00:16:01] RP: Exactly. And I would say it’s really inspired from two perspectives. One is the approach to extreme programming…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
