Exploring Software Architecture and Leadership

0:02 I often say one of the superpowers of being a consultant is you get to see lots and lots of different problems and solutions and attempts, some of which work and some of which don't. And if you're a natural pattern matcher, like a software architect, like you and I are, you start seeing patterns and you can write those things down. Understanding how things work at their core allowed me to look at agile engineering and understand why it worked as well as it did. It wasn't just a fad or cargo cult, but there was actually reason that it all worked. Hello everyone, welcome to this Tech.Rocks podcast and I'm having a very famous guest today, Neal Ford. I'm happy to have you here. I am Antoine Chantalou, I work at OCTO Technology and it's a consulting company.

1:03 I'm an architect. So I guess we will have the opportunity to talk together about architecture. So I'll let you introduce yourself. Indeed. Thanks for having me. My name, as you said, is Neal Ford. I work for ThoughtWorks, which is an international consulting company. I've actually worked for ThoughtWorks for, it'll be 20 years in April. I'm coming up on my 20-year anniversary of working for ThoughtWorks, and I've done a variety of roles there. Most recently, for the past decade or more, I've been focusing on software architecture and have been writing down a lot of the things in that software architecture as I discover them. Oh, okay, great. So very happy to have you. And if you can maybe tell me more about your career path, you know, I mean, how did you get there right now? Unlike a lot of developers, a lot of developers move around to a lot of different companies and, you know, a few years here, a few years there, startups, etc.

2:07 I never did that. I basically, when I left university, I did not go directly to university from high school. I took some time off and spent some time in the real world, decided I didn't like that very much. And so I went back to university and got my degree in computer science and joined the company and stayed there for over 10 years and then left that company and came and joined ThoughtWorks. And I've been here for 20 years. So I've actually only had two jobs. Professionally since I graduated from university with a degree in computer science. But I often say one of the superpowers of being a consultant is you get to see lots and lots of different problems and solutions and attempts, some of which work and some which don't. And if you're a natural pattern matcher, like a software architect, like you and I are, You start seeing patterns and you can write those things down. But I always feel compelled when I talk about consultant superpowers to also talk about kryptonite because those always come together.

3:08 And the kryptonite for many consultants is we don't get to see a lot of projects, you know, from. Beginning through inception, through maintenance, et cetera, through the entire lifespan of the project. But I think I've been fortunate in that I worked in basically two consulting companies since I graduated university. And that's a fantastic opportunity to see lots of different things and lots of different ways to approach problems. What works and why. If you had to name moments or discoveries that were key in your Or professional choices. What would you talk about? I saw this question and I'm going to go way back when I decided to go back to university. So I actually I was one of those that majored in a lot of different things because I couldn't figure out what I wanted to be when I grew up. And so I was an engineering major for a while. I actually went to a major engineering school and did enough of that math to realize I didn't want to do that the rest of my life. And I really loved computer science. And when I came back to computer science or to that, when I decided on that career and decided to go back to university, I had a fundamental choice to make at the university I was going to, which is Georgia State University here in my home state,

4:20 because they have a computer information systems degree and they have a computer science degree. And the computer information system is all this really practical, useful stuff like COBOL and SQL. And computer science was all this really exotic stuff like compiler theory and automata. And I definitely wanted to do the computer science stuff. And I did. And that was actually a really, really good choice because what it taught me was that you could learn superficial things like SQL. That's pretty easy to learn because it's just a set of facts. But learning how things work underneath is a lot more important. And that actually played well because I understood compilers. theory and how things work. And that translated to, so I grew up as a developer through my time becoming a software architect when Agile was a brand new thing and it was quite a radical thing. And Understanding how things work at their core allowed me to look at agile engineering and understand why it worked as well as it did.

5:26 It wasn't just a fad or cargo cult, but there was actually reason that it all worked. And so I think that has benefited me throughout my entire career, this idea of being able to look underneath things and understand. It's a famous quote that you understand one level of abstraction below the one you're working in. And I think I've managed to do that a lot in my career. So I think that was an important choice way back when to choose the more exotic path. But it turned out good in the end. Great. I totally understand what you're saying. I think it's important to understand, you know, on a high level and also to understand at a lower level. I have to ask you, Neal, what is a tech leader for you? I mean, a CTO, according to you, what is the quality to have as a tech leader? That's a great question. And I was fortunate enough to be able to basically tutor. So I actually was a CTO before I left. I worked for a small consulting training company.

6:28 And at our largest, we were refused. 50 people, but I was the CTO of that company. And I left there to come to ThoughtWorks. And I was fortunate enough at ThoughtWorks to get to work for more than a decade with Rebecca Parsons, who is a legendarily good CTO. And she showed a lot of the good qualities for a chief CTO, because I think one of the things that a CTO needs to have, particularly in a technology-focused company like ThoughtWorks, is a very, very strong voice. So there's a C in front of their name, but there's a lot of other C's that go to meetings, CFOs, CEOs, COOs, et cetera. And it's easy to get their voices drowned out, particularly when they start talking about things that seem esoteric or, you know, too abstract for the hardcore business, you know, the accountants, they don't want to hear about speculative technology. You know, they want to hear about bottom line. So it's really important to have a strong voice as a technology leader and have confidence in, you know, what you're talking about.

7:29 Now, confidence doesn't mean that you have a working crystal ball, but it does mean that you understand how things work underneath and understand the basis of how you have become successful from a technology standpoint. And let me explain what I mean by that. One of the things that Boltworks has always done extremely well, and this is at least in part, thanks to Rebecca, she didn't start this, but she was certainly a good shepherd of this, was that We understand good software engineering principles. It used to be called Agile Engineering Principles, but they just call them Software Engineering Principles now, I've noticed. Have you noticed that as well, that people have dropped the Agile part and they just call it Software Engineering now, which is notable to those of us who lived through all of that. But once you understand good engineering principles, when brand new things come along, How to incorporate those into good engineering practices is really key because you don't want to give up the good parts that you have, but you want to be able to embrace the future. So user experience design, when it first came out as a first class citizen, a common attitude was, well.

8:36 You know, those are precious geniuses. They need to work in isolation and they'll deliver their work to you and you can consume that. And we said, no, we need feedback loops. And we figured out a way to incorporate those in the feedback loops. We were one of the first companies to talk about continuous delivery for machine learning models. We're doing the exact same thing now for generative AI. Okay, generative AI is cool and it does all these magic tricks, but how do you get it into production with good engineering practices and good safeguards and guide rails and all those sorts of things? And so I think that is a good example of understanding the core principle of the organization. And understanding how technology applies and amplifies that, I think, is the best job a technology leader can do. Now, I want to know about your inspiration. Do you have, you know, daily inspiration? inspiration or are you reading books that has shaped your career? Well, sure. I have a lot of hobbies that are not technology-based, and so I'm an avid opera fan, and so I consume at least some opera every day because I love the creative aspects of opera and the artistic

9:50 parts of that, plus the music is not bad either. And I also read a lot of composer biographies. I'm really fascinated by the creative process. One of my favorite genres of books. are books by writers about writing. Stephen King's best book by far is his book on writing, which is his book that is a reflection on writing. So that fascinates me. There's a fascinating book called Rounding Wagner's Mountain, which is about the collaboration between Richard Strauss and Hugo von Hofmannsthal, his librettist. It turns out that one of them was a, the Hoffman stall was a recluse and hated to be in public. And so their entire creative correspondence was done through letters, which we now have, which is a fantastic treasure trove of how these works of art came together. So I'm always fascinated by that. But I'm always fascinated by one of the things that I've learned over my career, especially working in a really, a company with a lot of smart people in it, is that there's no one kind of intelligence. And it's important to understand how your particular flavor of intelligence works so that you can leverage it best.

10:54 And so I find that stepping away from technology and doing something completely randomly different like that helps me when I get back to technology stuff. So I try to spend some time. I exercise every day and just try to spend some time away from the computer and laptop as much as I can because it's always drawing me. Okay, I have a lighter question for you. If you have a totem animal, what would it be? It would almost have to be a cat because I have three cats and I study them a lot. But and I actually put this in the forward of one of my recent books. One of the things I've realized is really valuable about my cats is that they have a particular superpower, since I was talking about superpowers earlier, in that they never think about the future or the past. It's always right now, my cats. And as a person, it's hard for me to think about right now because my head is always somewhere in the future or the past.

11:55 And so anytime my cats want to come interrupt me, I let them interrupt me and I spend a little bit of what I call cat time, which is, you know, just surrendering to the now because they don't live anywhere else. They're always in the now. So I try to sync up with them. Let them distract me a little bit, which is another really useful distraction during the day. And so, but I watch them a lot and admire them a lot. They're a magnificent little creature. So it would probably be a cat of some kind. I have another question. Are there other famous tech leaders that would like to be, you know, or that inspire you? Famous tech leaders? Most of the current generation of tech leaders, I think, are way too one-sided toward a technology standpoint. My favorite one, as I was thinking about that question, would probably be Richard Feynman, the famous nuclear physicist. It was very eccentric, but one of the things that was most famous about Feynman, of course, he won a Nobel Prize because he helped create quantum physics. But he also has several computer patents for concurrency because he actually does designed a concurrent computer using humans back during World War II.

13:05 He figured out algorithms for, you know, he had women with adding machines and slide rules doing calculations for the military. And he figured out how to do concurrent programming using these people and, you know, stages, et cetera, and actually patented some of those. Feynman was actually very famous for going and visiting other sciences like biology and making suggestions that ended up leading to things like Nobel Prizes. So he was maybe most famous in history of carrying no preconceived notions and having the most open mind and the most fertile imagination of. Anybody that I've read about, perhaps, in history. So I would aspire to be more like him, probably, maybe a little less eccentric. One of the famous quotes about Feynman was that it was great that he won the Nobel Prize when he was young, because if you have a Nobel Prize and you act like that, you're just eccentric. If you act like that and don't have a Nobel Prize, you're a crazy person. So it was good that he... Won the Nobel Prize early so he could just be eccentric the rest of his life.

14:08 Okay, great. Now, I'd like to know, in technology, you know, everything is going so fast, it's hard to keep track. How do you keep up to date with technological developments? It's always a struggle, as you know. It's always an uphill battle to keep, because it is coming very fast. In fact, One of the books that I wrote, a couple of books ago, goes evolutionary architecture about, you know, the idea that you're never building and designing against a static ecosystem. It's always shifting and changing. New things are showing up all the time. So it's important to be up to date on those things. There are a couple of ways that I do that. One is trying to be very strategic about my learning time. So I have a fixed amount of time during the day. I have a lot of responsibilities. I'd like to have a bit of a personal life as well and spend some time with my cats. And so I don't want to spend all of my time trying to learn. And so my co-author, Mark Richards, has come up with a great scheme that I think works really well that I try to adhere to as often as I can, which he calls the 20 minute rule.

15:13 So his observation is, OK, you're ready for work for the day, whether you've gone to an office or your home office. And what's the first thing you always do? You open your email and now the rest of your day is ruined because you're just going to chase that for the rest of the day. So the 20 minute rule says when you first sit down with your coffee, but before you open your email, spend 20 minutes learning some brand new thing. That carves out some time every day to learn some new stuff, whether it's going to a D-Zone ref card to learn about some new details of something or looking at an article that you saved. So that's the other critical part of this is I think as architects, it becomes really important to be good at information management. Both project information, but also information for, oh, I really want to look into that more deeply, have a good way of saving that so that during one of your 20-minute periods, you can surface that and actually follow through on that. Because it's like sipping from a fire hose.

16:15 There's so much stuff coming all the time. Being able to grab it and organize it in a way that you can consume it and make sense of it, I think, is really, really important. The other huge benefit that I have is I'm lucky enough to be part of the group at ThoughtWorks that puts together the ThoughtWorks Technology Radar. So twice a year, we get together in person as often as we can, depending on global pandemics and other constraints like that. But in fact, in about a month from now, we're going to gather face to face in Bangkok, which is one of our more active offices, and put together the ThoughtWorks Technology Radar, which is always at thoughtworks.com slash radar. That is a unique publication in that the only way technology or technique makes it onto our radar is if a working project team has found success with it or, in the case of Hold, has been so annoyed with it that they bubbled it up through this entire process of gathering all those things.

17:17 And so we, when we get together as a group, we don't actually nominate any of those technologies. What we're doing is filtering through all of the things that have worked on all of our projects. So we have more than 200 software projects going worldwide. These are the best things that have been working in those projects. So it's unique in that it is practitioner curated. And all we're really doing is sifting through them and categorizing them and putting them together in about 100 of those. That's always a fascinating process to be part of. But a lot of other people can take advantage of that as well, because one of your or more than one of your 20 minute learning sessions can be looking at the radar because twice a year it is things that are. It absolutely worked to look really promising that have shown up on our projects. Now, it does not cover the entire technology landscape, nor does it try to. It's only things we have direct experience from, but it's unique in that it's a curated list of our direct experience. And I think you said you were also creating a similar radar.

18:21 To organize your thoughts about technology. Yeah, totally. I just published a tech trends and a tech radar for 2025 at Octo Technology, but it's mostly for the French market. But yeah, we consulted all the tech radar that we know, you know, and of course, the one from Sourceworks is for us a very good radar and a good inspiration. So yeah, we know it and we use it and we look forward to see the next one. But yeah, it's a very good radar. And I know because I just did it, you know, it's not easy to guess what is going to be the next big thing. But I know the trap, the pitfall, I mean, but it's not an easy thing to do. And I'd like to know more for you, 2025. Of course, we cannot talk about all the tech radar. But is there something that keeps you awake at the moment, something that you think is important that you want to talk about?

19:26 Well, certainly gender to the eye is the thing that's dominating everyone's conversation. And Mindshare now is how to make most use of that. It's actually less interesting to software architects than it is to developers because it's software architecture is about trade-off analysis. It's hard to teach humans how to do that well, much less a statistical pattern matcher come up with some good solution and trade-off analysis. That's always a fascinating thing. But the thing that I'm actually working on quite a bit right now, in fact, working toward my next. book with my co-author Mark Richards is this idea of architecture as code. So we've had infrastructure as code and security as code and a lot of these other things as code, but we haven't really had architecture as code. And at first glance, it's like, well, of course, architecture as code. That's like saying, you know, spaghetti as pasta. Well, of course. But I don't think people realize the degree in which you can actually drive your architecture through code now.

20:30 Sort of like we very gradually came upon Puppet and Chef and tools that allowed us to do infrastructure as code until suddenly there was this explosion of capabilities. I think we're right at the cusp of that. For being able to create architecture outlines and code and then build scaffolding for that. So that's the thing I'm currently working on with Mark. We're putting together workshops and it's going to be the subject of our next book. So that's the thing that I'm most excited about building examples for. Architecture as code, yeah. I look forward to read about that. Sounds great. Maybe a last question. We are reaching the end of the podcast. Do you want to share with us maybe a failure or a success story? I'm happy to share either one because I've had plenty of both. Success or failure, both. One of the things that we used to do, I used to do an interview as part of the keynote at the O'Reilly Software Architecture Conference. And one of the things we always ask experienced architects. is what is the biggest dumpster fire that you were responsible for?

21:35 So I'll talk about a failure that ended up being less of a failure than it seemed at the time. We had this giant project that the core of the project, they were basically trying to get us to replicate a very difficult thing. So I don't know if you remember Lotus Notes. Lotus Notes was a terrible, terrible, terrible thing. It was a terrible email client. It was a terrible collaboration tool. But it did one thing extremely well, which is offline synchronization. So you could be with Lotus Notes and disconnect from the Internet and answer all your emails and all that stuff. And as soon as you got back to the Internet, it's connect back and it would all sync up perfectly. And so that was great. In fact, the guts of that synchronization protocol left and went to several other tools and eventually, I think, became something like Dropbox. So we were tasked with building a sales tool that basically did this seamless offline synchronization because the salespeople wanted to work on the airplane. And as soon as they got back to the hotel Wi-Fi, sync it up and all this synchronization stuff.

22:36 So that was the core of the whole thing. And that necessarily drove a lot of complexity in the design of the thing. But that was the whole purpose of the thing working. And so. It had a lot of other issues like scope creep and a bunch of other things. And the client was very ambitious in the way they perceived the requirements, et cetera. And so there was a lot of. lot of complaining about the complexity that this protocol thing added. And so we finally gathered all the interested parties together and drew the architecture on a big whiteboard and said, okay, annotate the problem areas of this architecture and put sticky notes up there. By the time we were done, nobody had put a single annotation on the synchronization thing, which everybody was fussing about because it turned out it was code quality and it was database schema design. It was all these other things that were driving the headaches. But it was a convenient scapegoat to say, oh, there's this weird thing in this project. This must be the thing that's driving all the complexity and the headache. And it's like, no, this was actually kind of a core requirement.

23:37 So while it was sort of a failure in that we couldn't contain the client's desire to keep adding new features to it and causing scope creep, at the end of the day, the thing that we had designed it for, it actually worked okay to do that. So it's kind of half success, half failure, probably. Thank you for sharing. Okay, we are at the end of this podcast. I'm very, very honored to have you for TechWorlds, Neal. Thank you so much for your answers. And we look forward to read your TechRadar and book, Architecture as a Software. What will be the name? Architecture is code, we think. Thank you so much. Thank you so much, Neal. Thanks so much for having me. It's always a pleasure to talk to Tech.Rocks. And have a great day.