This week we dive into evolutionary architecture.
Support constant change
Michael C: Hey everybody, this is Michael Carducci, your host. You’re listening to the No Fluff Just Stuff Podcast. This week I am joined with the legendary Neal Ford. Neal Ford is very prolific, speaker, author, and professional meme wrangler, I believe, at ThoughtWorks. Neal, say hello. Introduce yourself, please.
Neal Ford: Hello there, it’s nice to be here. I’ve been on the No Fluff tour since 2004.
Michael C: You might be the longest-
Neal Ford: Nope, Venkat.
Michael C: Venkat has the most, the longest tenure.
Neal Ford: A couple people have done a few longer than me, but I’m getting up there, but I’m never going to be Venkat, so, you know.
Michael C: I don’t think anybody is ever going to be Venkat.
Neal Ford: Well, you know, hat’s a record that doing all 11 talks, plus the keynote, is the most you can do. And so,Venkat both achieved that at some point, but then Venkat, being sneaky, actually did a special session one show instead of the Birds of a Feather so that he could actually do 13 slots, and thus hold the record forever because no one else will ever surpass that.
Michael C: I don’t think … I’m not sure anybody else would want to.
Neal Ford: Oh, exactly. That’s a …
Michael C: You know, to quote Nate Schutta, “He’s incredibly lifelike, isn’t he?”
Neal Ford: He is indeed. His only vice is hanging out with us.
Michael C: Yes. I talk about Venkat sometimes. Venkat is one of the speakers on the No Fluff Just Stuff tour. I believe he averages about three or four hours of sleep. He wakes up at, typically, 3:00 or 4:00 AM and, you know, in his morning routine he’ll write a book, he’ll write a session, and then he’ll go and do some consulting work and then he’ll go and teach at university and then he’ll fly out to Europe to speak at a job and he’ll fly back to work at a conference for four days straight all day, every day. And on the plane he’ll probably write a book, because I guess he can’t sleep.
Neal Ford: Well, and this year in addition to all of his other stuff, he’s decided to do 50 Java users groups within this year. And he’s on this tour all over the world doing Java users groups.
Michael C: That’s the crazy thing. He’s not just “Okay, well, I’m gonna do three in Colorado and then I’m gonna go up into,” you know, wherever else he’s flying out to, like Helsinki and then he’s going from Helsinki over to do one in San Francisco, and then San Francisco he’s gonna go to Copenhagen and … it’s insane. Although he is getting his frequent flyer miles in and that’s important.
Neal Ford: Definitely is.
Michael C: But Neal, so one of the topics you speak about at length on the tour here is, you know, topics, they tend to be focused around software architecture. And that’s kind of really your area of expertise, that …
Neal Ford: Right now it is. That’s why I spend a lot of my professional focus at Thoughtworks, because I split some of my time doing professional services work and then some time doing speaking and writing. And several of us have been talking for several years about this idea of … ’cause architecture seems to be brittle, and it’s hard to change. In fact, for a long time colloquially, we said that architecture’s the stuff that’s hard to change later. And that was kind of our definition of architecture. But then …
Michael C: That’s why you’ve got to get it right the first time.
Neal Ford: Exactly. But then we saw some architecture like microservices that encouraged change, and they don’t punish you quite so hard. And so we started thinking more deeply about what is this family of architectures that would let you encourage change rather than try to avoid it? ‘Cause there’s a fundamental problem in software. So I would say that when we think about change, we normally think about change as one thing. But in software it’s actually two things. There’s business change, which is, we’re changing requirements or we’re merging with another company. And that’s really what the agile movement’s been trying to hack at and attack for the last 10 or 20 years. But there’s also another kind of change that we’ve done more poorly with, which is this accidental ecosystem change.
So I’ve been meeting with a lot of enterprise architects over the last year and I keep making them all a wager, and none of them would take me up on this. I’ll make you this wager.
Michael C: All right.
Neal Ford: See if you’ll take me up on it.
Michael C: You know how much I love wagers.
Michael C: Probably not.
Neal Ford: So in the realm of five-year planning, it’s insane to try to plan what you’re gonna be doing five years from now, because the ecosystem is gonna be fundamentally different in a few years from now. And so you’ve got to build adaptability into architecture. We really need this idea of being able to change. And we’ve dealt poorly with this ecosystem change that’s kind of forced on us, because new things pop up all the time and you have to take account for those things. ‘Cause sometimes they have an impact on the kind of things you’re building.
Neal Ford: Exactly.
Michael C: I have an application that I still maintain that’s using U, it’s using YUI, and I don’t even think … I think that ceased being a thing a decade ago.
Neal Ford: Right, exactly. But there’s a … you know, if you go back before the Internet, this is aging me, we used to have bulletin board systems.
Michael C: I remember those. I dialed into those.
Neal Ford: So there was a programming bulletin board that I went to frequently, and they would always have an intro screen and then a logout screen, where they’d give you some pithy message. And I remember this one programmer bulletin board that I used to go to, said this and it’s still true, it said “You may be able to C forever,” the C programming language, “but Cobalt still prints your paycheck.”
Michael C: Oh.
Neal Ford: And that’s still true now.
Michael C: That’s still true now.
Neal Ford: Exactly. That was true 25 years ago, it’s still true now, because exactly to your point, when software does useful things, you tend not to just rewrite it for fun. You just leave it there until you have to rewrite it for some reason.
Michael C: And that’s the thing that I noticed that used to blow my mind as a young software engineer, you know, I’d go to get my car serviced and at the checkout desk where they’re doing, they’re printing up my little thing, they’re printing it out on a dot matrix printer. And the computer that they’re running their little business system on is running DOS. And not even like a current iteration of DOS, like DOS 6.
Neal Ford: Yeah. My mother’s a court reporter, and that’s all WordPerfect, the entire world. And when she learned WordPerfect, it was on DOS on a particular kind of computer, and she now has a guy who can come over to her house and install DOS still on modern computers, and WordPerfect 6, so that she can have this perfect environment that she wants. ‘Cause she’s tried Windows and Macs. Nope, I want WordPerfect 6, DOS, this perfect thing.
So this is an inevitable part, a feature of our lives. So our book is really about how do you adapt to those kinds of inadvertent changes that come along?
Michael C: And so this is the book, Designing Evolutionary Architectures?
Neal Ford: Building Evolutionary Architectures.
Michael C: Building Evolutionary Architectures. So that’s O’Reilly?
Neal Ford: Yep. It’s O’Reilly, came out about four months ago, it’s on Safari and all the booksellers and all the different formats you would expect it in. But there’s sort of unusual side effects of putting some of these things in place. Our definition of an evolutionary architecture is an evolutionary architecture supports guided incremental change across multiple dimensions. The multiple dimensions we talk about is every aspect affected by your piece of software. So we include a chapter about relational database design and how to evolve it, because you can’t just evolve your architecture and leave your schemas behind, because you quickly hit a dead end.
Michael C: There’s a number of challenges around that, too. I was a DBA for a very long time. By the way, just as a side note, you know what DBA stands for, right? Don’t Bother Asking.
Neal Ford: There you go. Well, and you know, there’s a great book, Refactoring Databases, by Scott Ambler and Pramod Sadalage, that talk about a bunch of those things. But that’s one of those things, that’s one of the dimensions you have to think about.
And also some other things that are really part of architecture but we don’t often think about them as part of architecture, ’cause they live in a different silo, like security. Well, that’s really something we need to take into account, because what I don’t want to do is choose security as one of the important characteristics I want to guard in my architecture and then make changes that degrade security. That would be bad. We try to avoid that, and so security is an important architectural concern, even if there’s a separate division in your company that’s worried about it, it’s still something that falls under our definition of one of the dimensions affected by change.
But the main new idea in our book is this thing that we borrowed from evolutionary computing, which borrows it from evolutionary biology, which is this idea of a fitness function. So in evolutionary computing, you have a fitness function that tells you how close your genetic algorithm is getting toward its goal. So in evolutionary computing, you have genetic algorithms that have known ways of mutating themselves, they can make changes and try the solution again. And so the fitness function is the thing you evaluate after it’s mutated to see, are you closer or further away from what I want.
Michael C: Got it.
Neal Ford: So let’s say you’re designing an airplane wing. Every time it creates a new design, you’re gonna try to evaluate it in terms of lift and weight and materials and shape and all the … that’s the fitness function for the airplane wing. And so we’re borrowing that concept for architecture. So let’s say that you’ve chosen a particular architecture pattern because of scalability. Because that’s an important concern in your architecture. Well, what an evolvable architecture means is that as I make changes to my architecture, both purposeful and ecosystem changes, scalability doesn’t degrade ’cause I’ve chosen that as one of the important characteristics of my architecture, and so what we’re gonna do is build mechanisms around scalability to test it, to make sure that we preserve those characteristics. That’s a fitness function.
So it could be a unit test, it could be metrics, any of those. Our definition of an architectural fitness function is any mechanism that gives you an objective integrity assessment of some architectural characteristic or combination of them. And so we’re scooping up a whole bunch of things that already exist out in the world, like for example JDepend is a great library that lets you write unit tests around how components are connected to one another. You can define rules that say okay, it’s okay for web to import util, but I never want util to import web. You can actually codify those rules and have JDepend check it as you check in your code. That, for us, is an architectural fitness function.
But the best example of one of these is the Chaos Monkey.
Michael C: Okay.
Neal Ford: This is an example of what we call a holistic continuous fitness function, which is one that runs all the time and checks a combination of a bunch of different features. So I’m sure all of our listeners are familiar with the Chaos Monkey. This is when, Netflix had to move all of their infrastructure to AWS. They worried that “We don’t own our own infrastructure, and what happens if it misbehaves?” And so they created the Chaos Monkey, which makes AWS instances misbehave in a variety of different ways. And they created the Chaos Monkey, the latency monkey, the doctor monkey. And what the doctor monkey does is sniff around their ecosystem and check to make sure that rest in points are configured correctly.
And they also have the Chaos Gorilla.
Michael C: Which will shut down an entire …
Neal Ford: Data center.
Michael C: Yeah.
Neal Ford: So about eight months ago, very famously, Amazon accidentally killed Amazon East by fat-fingering [crosstalk 00:10:45].
Michael C: A single command.
Neal Ford: Not enough automation, that’s bad. And so I have one of those ring doorbells that gives you a little video when people approach your door. Well, it turns out when Amazon East is down, it’s just a regular doorbell. No more videos. But while Amazon East was down, Netflix stayed up because the Chaos Gorilla simulates an entire data center going down. But this is a great example of this idea of a fitness function, because they don’t run the Chaos Monkey at 3:00 on Tuesday afternoon. Chaos Monkey lives in their architecture. So if you’re a Netflix engineer and you try to write a service that’s not resilient and put it live, the monkey’s just gonna kill it. And so you don’t have the option not to do the right thing.
And so what fitness functions become is an automated way to apply architectural governance. So right now, not too long ago I went to one of our clients, and they’re in the process of replatforming their system. And when we showed up, they showed us the spreadsheet they had created, had 66 rows on it. Here are all our aspirational goals for our next architecture, and there were like four ninths resiliency, and all these things that they wanted. And I said …
Michael C: Things that look really good on a spreadsheet.
Neal Ford: Exactly, and I said “This looks awesome, that you delineated all these things, but when I come back in six months, how many of these things are still gonna be true?” And maybe more to the point, how easily can you tell me if they’re true? ‘Cause a lot of times, architects define these really highfalutin, very nice-sounding things, but then they have no way of verifying them, ad hoc at best, and you just never get around to it.
Michael C: That’s the glorious thing about being an architect, you can just kind of make these proclamations from your ivory tower, and then it’s somebody else’s problem.
Neal Ford: The prettier the drawing …
Michael C: That’s right.
Neal Ford: I was with a group of enterprise architects in Sydney, and they had recently moved their office specifically to get out of a building that was colloquially known around the city as the Ivory Tower. That was just the wrong optics in a group of architects, to say “you need to go see the architects in the Ivory Tower.” It’s like no, no, no.
Michael C: No, no, no.
Neal Ford: Even though the offices weren’t as good, they decided they needed to move. But now …
Michael C: Yeah, that was probably wise.
Neal Ford: The idea of a fitness function gives you a way to automate that. So here’s a great example that I bring up to enterprise architects everywhere. It’s a really well-known metric, and all programming languages that are structured, cyclomatic complexity.
Michael C: Yep.
Neal Ford: How complex a function or method is. And so I ask these enterprise architects, what’s the most complex function or method within your entire enterprise?
Michael C: You should be able to just pull that up, I mean, and most IDEs now will just have these metrics built into them.
Neal Ford: For a particular code base, but nobody’s done it globally. And they get this look on their face, like “Ah, I may be afraid to look at that.” So what if, so what if … so one of the interesting things that DevOps taught us is that automation creates a platform. Once you have a platform you can leverage that to do some interesting stuff. And so let’s say, so one aspect of incremental change for us in evolutionary architecture is this idea of a deployment pipeline that runs multiple stages upon check-in. So what if you could assume for a moment that every single one of your projects was running a deployment pipeline as the way that they build all their stuff. Now your deployment pipeline has a slot in it for enterprise architect fitness functions, and one of the ones to put in place is to say “No code with a cyclomatic complexity over 50.” And just keep it from going crazy, because now at least you have a global check on this characteristic in your architecture to make sure that nothing goes terribly wrong.
So let me give you a good example of how this is applied. One of our clients. So we had fitness functions in place in this application, and this developer, novice developer, brand new hire, needed to write some code that doubled all 50 states. And so in Java they wrote this method that said “if state equals Georgia, then do this, else if state equals Alabama, else if state equals Michigan” for all 50 of them.
Michael C: Yep, sounds like code smell, but okay.
Michael C: Oh.
Neal Ford: Bypass the back end. And so he wrote the same thing in the front end, with all 50. But the architects outsmarted him, ’cause they had a cyclomatic complexity check on the front end too. And that forced this junior developer to go to one of the architects and say “Look, it won’t let me check this code in, what’s wrong, what do I need to do?” And that’s the day he learned about the strategy design pattern and the reason you don’t write a single method with 50 “if” statements in it.
But see, that’s architectural governance. As an architect, wouldn’t you like to be able to put at least a few sanity checks in place across your organization to make sure that those kinds of things don’t happen? This allows you to automate that kind of architectural governance that has been ad hoc and therefore ignored for a long time.
There’s another great example of this. So let’s say that one of, again, all of your teams are running deployment pipelines, and your security team has a slot in your deployment pipeline. They’re probably not running any kind of crazy, sophisticated testing, but we have-
Michael C: We have to at least do some static analysis from the security standpoint.
Neal Ford: Static analysis, maybe penetration analysis, there’s some automated things you can do from a testing standpoint. It wouldn’t be comprehensive security, but at least a check.
Michael C: Yeah, and you want to … and even if nothing else, you’re catching some of these low-hanging fruit that would otherwise slip through.
Neal Ford: Well, and in particular, the low-hanging fruit you desperately need to check. So what if, for example, we’ll make this purely hypothetical, ’cause this would never happen to like a major financial institution or anything.
Michael C: Surely not.
Neal Ford: So zero-day exploit came out for Struts. You know, something just purely hypothetical. How confident are you within your enterprise that everybody that’s using Struts is patched? You know, somebody’s going around looking at that, you know, this is one of the things that nabbed this famous company, is that they had several instances of somebody forgot to patch. But what if every single project, every time they did a build, had a deployment pipeline and security had a link into that. And they don’t have to write a security test for Struts, but on the day the zero-day exploit comes out, they have inserted tests into all those deployment pipelines and said “If the version of Struts you’re using is this, fail your build.”
‘Cause I don’t want that code deployed. I know it’s gonna be inconvenient for you today, but I do not want a code with a security violation deployed. This allows you to automate even things like security checks that have been ad hoc and manual and otherwise difficult to [crosstalk 00:17:14].
Michael C: As we think of it, as we remember it.
Neal Ford: Exactly. And so this gives you a kind of a substrate. It gives you a platform for dealing with both local project concerns, because a local project’s gonna build fitness functions around the characteristics for that application they want to support. But you can also support this idea of global governance around some architectural characteristics that you need to support company-wide. Elasticity’s a great example of one of those, just like Netflix does. If you’re building a microservice architecture, you may insist and want all of your services to be lasting. And so here’s an example of a really easy fitness function to write.
So let’s say I was trying to write a fitness function for elasticity in a microservices architecture. What I really want to test is just that I can create an instance of the service, send it enough requests for it to go elastic, and make sure more instances pop up. So most of that is handled in a service template in a microservice architecture, so what I’m gonna do is create a hello world microservice, put it in a service template and stantiate it, send it enough requests to go elastic, and verify that more instances are created. I now have a fitness function for elasticity. And if I wire that in, now none of my developers who are writing services can cheat on that, ’cause now every time I make a change I’m testing to make sure that architectural characteristic has still been supported.
Michael C: So I want to come back to the evolutionary computing aspect of fitness functions. Because a fitness function in that context, the goal is to tell you how close you are, or the aim, rather, is telling you how close you’re getting to your goal. Is that the same thing you’re doing with fitness functions in architecture, or is that just a true pass-fail, that it’s either at this level or it’s not?
Neal Ford: Well, some of them are true pass-fail and some of them are dynamic. So for example, you may be willing to withstand a lower performance number as scale goes up. So there may be a sliding scale on those. So, but ours is a little bit different, and that’s why we say ours is guided. Because in the evolutionary computing world, you’re trying to build some criteria that lets this automatic mechanism build something that meets that criteria.
Michael C: Yeah.
Neal Ford: We could probably do that, but it would take a few thousand years to build a cool architecture ad hoc by letting it evolve. So this is the guided part. So as architects, we’re basically shepherding the characteristics we want into the future.
Michael C: So you’re getting more and more of that, you’re getting closer and closer. Because that’s always been my perspective on this whole thing, that engineering is not about this ideal, perfect solution. It’s about doing the best with what you can. And so that’s one of the aspects of evolutionary architecture is … like, when I think of evolutionary architecture, I think about okay, like I’ve worked in a bunch of startups. I’ve dealt with a lot of day zero problems, getting from zero to one. And so I’ve always tried to make enough of the right decisions that when, you know, that when scalability becomes our problem or extensibility becomes our problem, not just getting something to market, we can take this and build off of it and evolve that architecture.
And so that’s always what I kind of think about that, but there’s another aspect of it as well. It’s possible, I feel, to spend so much time thinking about having a truly extensible and resilient and adaptable and agile infrastructure and architecture that we can spend so much time designing that agility into the infrastructure that we never actually build anything.
Neal Ford: Of course.
Michael C: So how do we find that balance?
Neal Ford: Well, I mean, the microservices world is kind of forcing you to find that balance, ’cause a lot of that stuff is built into service templates in the operational side of services versus the business side of services.
Michael C: Yeah.
Neal Ford: So a lot of that kind of behavior is spread out. And certainly you can go down a rabbit hole here of building too much stuff. But one of the things this forces you to do is to really evaluate the cost of what scalability costs. ‘Cause if you go to business people and say “You know, of these 15 different architectural characteristics, which one do you want?” They’re always gonna say all of them.
Michael C: Oh, yeah. So …
Neal Ford: It’s well, okay, but which one … and so this actually gives you a way to prioritize them, because now the cost of that becomes what, the cost of implementing it and maintaining it to make sure it doesn’t break. Which means we’re gonna have to create and maintain fitness functions for it. And that gives you a real way to assess what does it really cost us, in real dollars, to have a scalable architecture? ‘Cause now, it’s hard to say because it’s just in this bucket of other architectural characteristics that we’re sort of trying to maintain. This forces you to be a little bit more formal about which ones do we want to support, which ones are more important …
Michael C: And a little more objective as well.
Neal Ford: Yeah, absolutely.
Michael C: To quote who I might say is the most quotable person on the No Fluff Just Stuff tour, “Developers are drawn to complexity like moths to a flame, frequently with the same result.”
Neal Ford: The same result, yep.
Michael C: And that, for our listeners, is a quote that I attribute to Neal Ford. I honestly believe I quote Neal Ford in my talks more than anybody else. Not just on the tour, but in our industry in general.
Neal Ford: Well, I am a meme wrangler.
Michael C: Exactly.
Neal Ford: That’s where most of it comes from.
Michael C: So the new book, Building Evolutionary Architecture, it sounds like it’s another kind of comprehensive piece. If I were to read this, I mean, what’s your advice on this? Is this something that I would dip into and look at different topics? Is it something that is worth reading cover to cover?
Neal Ford: You can. Certainly the first chapter is kind of the intro, the concept, and our definitions. Second chapter is about fitness functions, and then the rest of the book is really about how to apply these things, what incremental change means. There’s a bunch of stuff about migrating architectures from one style to another and how do you support that, and how evolutionary particular architectural styles are. One of the things that we did in the book was, you know, Eric Evans’ Domain-driven Design has been very, very influential in architects, and we talk about bounded context. Well, we actually formalized that at the architectural level, refer to that as the architectural quantum, which is a deployable unit that is singular within your architecture, and so we found that one of the ways that you analyze how evolvable an architecture is is look at the quantum of the deployable units. So that’s one of the advantages of microservices, is they have a really small quantum because it’s a very small size, versus a monolith.
Even if you built a really good modular monolith, the tradition in monoliths is to deploy the entire thing. So the quantum is still the entire system, even if you have better modularity within it. So it’s never gonna be as evolvable as microservices ’cause the quantum is a lot bigger. And so that’s another one of the science things we kind of borrow in our book from Eric Evans.
Michael C: Sure.
Neal Ford: We do have a chapter about evolutionary data, and we also have a chapter about how to sell this to places like enterprises, and also how to utilize some of this to do … we have some case studies on how to do things like data-driven development. There’s a great case study on the Github engineering blog called “Move Fast and Fix Things.” You can go look it up, and it’s about how they replaced a merge on the Github site over the course of four days while doing 60 deploys a day, and replaced it with no regressions, and accidentally found a couple of other bugs with other pieces of their ecosystem.
Michael C: Wow.
Neal Ford: By running this piece of software called Scientist, which runs basically the old code, but runs the new code in parallel selectively and compares them, and allows them to chase away bugs and it replaces the old code.
Michael C: Really? That …
Neal Ford: It’s a great example of an evolutionary architecture.
Michael C: That’s incredible.
Neal Ford: Make a structural change in an architecture without breaking stuff at the same time.
Michael C: And so they were doing kind of the automated comparisons?
Neal Ford: Yeah, what Scientist does is it creates a block. You have “use” and “try.” “Use” is the old way you used to do it, “try” is the new way you’re trying. So for the merge experiment, for 1% of users, they got … you always get the result of “use,” so it always runs “use.” So the worst case, if you fall into the experiments, you get exactly what you would have gotten before, but in that 1% case, they also run “try,” compare the results to “use,” compare the timing, ’cause they were trying to build a more performant version [inaudible 00:24:42], and then publish all the results on the dashboard.
Michael C: That’s incredible.
Neal Ford: It’s great, and it was a great idea, and it’s a great example of how … so a lot of people think agility implies bigger risk, but in many ways it’s even less …
Michael C: It was zero risk in that, yeah.
Neal Ford: Exactly. And they did this while doing 60 deploys a day.
Michael C: That’s incredible, yeah.
Neal Ford: It’s a great case study, and it shows exactly the power of designing, being able to build adaptable architectures. ‘Cause for us, all Scientist is is a fitness function.
Michael C: And you know, other things you’re doing and you speak about here on the tour, things like feature toggles and all these things as well …
Neal Ford: And the other thing that Scientist is is a feature toggle library, ’cause at the end of the day, that’s what it’s implemented as, a feature toggle library with some metrics built in, but built for a very specific purpose, which is let’s do architectural restructuring.
Michael C: Yeah, that’s … wow, I’m gonna dig deeper into that, but I know we’re probably running out of time. Is there anything else you want to cover?
Neal Ford: So I mentioned the book, we’re also going to produce a series of videos on Safari for O’Reilly around the topic of the book.
Michael C: And anybody who’s seen any of Neal’s architecture videos on O’Reilly, everything that’s out there, the vast body of knowledge, you will know what you’re getting, and so that’s kind of exciting as well.
Neal Ford: Well, and … so one of the things that I think a lot about lately is what’s the appropriate kind of media for IB? Well, a lot of stuff I’ve been doing lately is video because video’s just an easier thing to do in many cases. But we thought this was fleshy enough to write a book about. But we also created a video for it as a way of popularizing these ideas too. And we also have a website called EvolutionaryArchitecture.com. And, so one of the things that people ask us about all the time, what are good examples of the kind of things you build fitness functions for? So if you go to EvolutionaryArchitecture.com, there’s a section on the page called Fitness Function Katas, which are little fitness function exercises that we work through when I do the workshop. We work through a bunch of those exercises. And in fact, I’m doing a talk on No Fluff next year about defining and building architectural fitness functions, and we’re gonna do hands-on exercises to identify and build these things as a way of learning all the different avenues you can take to protect your architecture.
Michael C: And I truly believe that is the best way to learn architecture. One of the biggest challenges is, as a practicing software architect, you might build one architecture a year, right? You might go through this exercise once a year.
Neal Ford: If you’re lucky.
Michael C: If you’re lucky, yeah. I mean, you have the luxury of working for a company like ThoughtWorks, that you’re brought in to many clients and this is something you’re doing over and over again. You know, I talked to Matt Stein, who does the same thing. I mean, his job is to come in and rescue failing architecture. And so they’re doing that over and over again. I mean, that’s where you get that tremendous amount of experience, but taking that experience, distilling it into those katas, that you could come in for a workshop or for a day or for a conference and just go through all these exercises and learn these lessons that people would typically learn over years or decades in the industry. I mean, I applaud that. I know it’s a lot of work to put those together.
Neal Ford: Well, we really, Mark and I have been doing architectural katas for a while, ’cause we really love the hands-on aspect. You really don’t learn something till you can really get your hands on it. Architectural concepts are hard things to get your hands on.
Michael C: Well, ’cause they’re a little more abstract.
Neal Ford: Yeah, they are, absolutely. So we’re figuring out ways to build exercises and have a chance to actually apply some of this on your own. ‘Cause once you see a few of these things in action, it starts really clicking. It’s like “Oh, I see exactly how to solve this problem.”
Michael C: Why we’re making this decision and … yeah.
Neal Ford: Yeah, exactly.
Michael C: Well, I’m really excited to check it out and see what you have on the tour in 2018. Neal, thank you so much for joining us. Anybody wants to track it down, obviously Safari, O’Reilly, the book there. If they want to follow you on Twitter, what’s the …
Neal Ford: It’s Neal Ford, N-E-A-L number four, D.
Michael C: Four D, yes.
Neal Ford: Ford’s my leet speak name.
Michael C: All right, perfect. Neal, thank you again, and for everybody out there, thanks for listening. Look forward to seeing you on the 2018 No Fluff Just Stuff tour.
Neal Ford: Thanks, my pleasure.