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
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. And you know, the tagline for extreme programming is “to embrace change”, you don’t know where it’s going to come from, but you know what’s going to happen. So, you know, just decide that’s a good thing. And then from the field of evolutionary computation. But one of the important parts of evolutionary architecture is the recognition that even though you know, change is going to happen, you don’t know what that change is, is going to be. And so the more you try to anticipate it, oh, I’m going to build, you know, under an adapter to allow me to plug in different approaches to this problem, because I know that’s going to change. But what happens if that’s not where the most disruptive change is coming from? What have you done? You’ve increased the lines of code, you’ve increased the complexity of the code, you’ve introduced more bugs because bugs are correlated with lines of code. You’ve probably made the architecture and the program more difficult to understand. And, when the change happens, that doesn’t correspond to what you predicted was going to happen, you probably have a harder time making the change that you have to make, because you’ve got all of this other stuff in there. And so the basic premise of evolutionary architecture is rather than trying to predict how things are going to change, have your system and your architecture in a position where it can adapt as quickly as is possible to whatever change happens, while maintaining the integrity of the technical, the architectural characteristics that you think are important. So, we can’t say everything’s going to be easy or quick, but the intent is to make it as easy as possible and as quick as possible to make whatever changes are necessary as a result of whatever development might have happened. Whether it be In the technology landscape in your business requirements in the hardware that’s available to you, or changing regulations, or whatever it is that’s causing you to have to change your system.
[00:18:11] ES: What’s an example that you can think of a decision that was made for an architecture that allowed it to have these characteristics of evolutionary?
[00:18:22] RP: So there was a colleague of mine who was telling me about a system that he was building. And there were two competing approaches to how the various components of the system, we’re going to coordinate their activities. And most of this team wanted to go one direction, but he felt strongly that this other mechanism was going to work better, but he really couldn’t articulate why. And he never really managed to convince the rest of his team that he was right. And so what they did is they looked at how the system would be different, how they would implement the rest of the system differently, based on the choices that they made of this coordination mechanism. And then they effectively built an abstraction layer. And then they went ahead and implemented what he thought was right. And a couple of months later down the road, he acknowledged that he was wrong. And they were right, and that they should have done this in a different way. And because they built that abstraction layer, it wasn’t hard for them to switch to the other approach. Now, I’m not advocating that everywhere you could possibly think of something potentially changing building an obstruction layer, because that, again, just makes things more complicated. It’s more code, but in this particular case, they knew that they didn’t have enough information to make this particular decision. And so they constructed this abstraction layer as a way of allowing them to change that part of their system with a minimal amount of change. So that’s one example. Another example, if you think about a microservices architecture, the level of encapsulation that micro services have, really allow you to make very isolated decisions about how a particular micro service is built. And, so if something radically changes, and you want to implement a microservice in a very different way, you can do that without touching any other service within the ecosystem. So that’s another form or another way to achieve an evolutionary architecture, is just that that level of encapsulation. And you’re trying to look at the encapsulation from the perspective of what types of things fit together from a business perspective. And so when you talk about microservices architecture, we talk a lot about the bounded context idea from domain driven design because that gives you a logical business relevant back boundary, an encapsulation boundary to draw around a microservice. So those are just a couple of examples.
[00:21:05] ES: So it sounds like during the process that involves a lot of leveraging previous design patterns and some architecture patterns, right?
[00:21:15] RP: Yes.
[00:21:16] ES: Got it. Before we finish, I just want to switch gears a little bit. So I want to talk now about something that I hear a lot, which is that women leave the tech industry at higher rates than men. You’ve been in technology for over 30 years. What are some of the reasons why you’ve stayed intact and why you enjoyed what you do?
[00:21:38] RP: Fundamentally, I’m a geek. I’ve always known I was a geek. When I was introduced to programming, I found a very specific way of expressing my geekness. I am passionate about technology. I can’t imagine doing something else. It continually fascinates me, the potential to solve problems, the pace of change and the ability to learn new things. I just find it fascinating. I’m passionate about it the way painters are passionate about painting or musicians for performing. I just can’t imagine doing anything else. And I think that’s been why it just hasn’t mattered to me that people didn’t think I belonged in technology, because of course I do. I mean, it’s in my blood. I can’t imagine doing anything else.
[00:22:29] ES: So you’re saying you did have instances of, you know, feeling different, you know, by the people that you’re surrounded with. But that didn’t really get to you because your love for it is very strong.
[00:22:42] RP: Yes. I mean, I had a professor when I was an undergraduate, who got up in front of a class and said, “women are incapable of understanding math and computer science”. And there were three other women in that class with me and we all bonded together and said, we’re going to prove this guy wrong. And all four of us ended up with As. many of the men got Bs and Cs, some dropped out. None of us dropped out. We all got A’s. And it was like, we’re going to demonstrate to you, that you are wrong that this has nothing to do with me being a man or a woman. This has to do with, some people are good at something. Some people are good at others. And I was really lucky in that my parents instilled in me and my brother and sister, this just inherent confidence that whatever we wanted to do, if we worked hard, we could do it. And so it never occurred to me that I couldn’t learn something or I couldn’t do something because that’s just not how I was raised. I was raised to believe that if I wanted to do something, if I set my mind on it, if I worked hard, I would be able to do it.
[00:23:44] ES: That’s great. That’s really good that you were able to prove people wrong. So good approach. I think one more thing that I wanted to ask you about is you are the recipient of the Technical Leadership Abie Award back in 2018. What does getting this award mean to you?
[00:24:02] RP: I was overwhelmed. When I was chosen for that award, we have a saying in inside ThoughtWorks that everyone is a leader. And I truly believe that but to be recognized by an organization like AnitaB.org as a technical leader, that was very humbling. I look at the other winners of the award. And it’s hard for me to think about being in that cadre because they’re, you know, some truly incredible women with, you know, tremendous accomplishments. And so I felt very honored, very humbled to be chosen for that award.
[00:24:38] ES: Do you think also getting this award had any impact in your career?
[00:24:42] RP: it just reinforced many things that I already had felt was important. I believe very strongly in role models in providing support to others. And so that just reinforced in me this desire to not hide under a rock. So I do podcasts like this. I give conference talks. And I get up on stages and such because I believe it’s important for young women who also have a passion for technology to be able to see other women up on stages like that and hear their stories and get that same sense. Of course, I can do this. I love technology. And I want to and I can be a part of this
[00:25:24] ES: Last question. What is some general advice that you would give to young professionals? It doesn’t have to be, tech related, just what are some thoughts that you would say to them,
[00:25:37] RP: To never be afraid to learn something new. So many people, when they think of learning, they think of school and you know, the teacher at the front of the desk and tests and all of that, but learning is so much more than that. And, if you approach your career and your life as what’s something new that I can learn today. What are questions that I don’t know the answers to that I can go off and answer or figure out how to answer. It keeps the world fresh, it keeps your career fresh. And I think it also helps us address some of the problems that the world has. So just don’t be afraid of learning. Just because you don’t know something doesn’t mean you can’t do it. Just go ahead and try anyway.
[00:26:23] ES: Well, Rebecca, thank you for coming on the show. It’s been great having you.
[00:26:28] RP: Thank you so much for having me.
Sponsors
The Women in Tech Show 