i think knowledge transfer is huge problem right i mean you know it's if you only have one person that knows one part of the code and obviously the bus factor or the lottery ticket factor if they win the lottery and they're gone You know, nobody knows that area of the code. From Tuple, this is Distributed, where we show how world-class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. Let's get to the real work.
We are speaking with Josh Kariefsky today, one of the earliest pioneers in agile software development and the founder and CEO of IndustrialLogic. Welcome, Josh. Thanks, Jock. Pleasure to be here. Yeah, well, we're excited to have you on the show because you obviously make a living coaching teams about how to do software development better. And distributed is all about uncovering how great engineers and their teams approach.
software development in light of our new normal where various forms of remote and distributed work are the norm. Given you are one of the earliest pioneers of agile software development, when did this idea of agile really click? for you, Josh. It clicked for me in the 90s when it was called Lightweight Software Methods, and we were experimenting with, you know, approaches that were just different from doing things in a...
Classical waterfall style, of course. And really, if you even go back in time, several decades before that, there are many instances of agility or agile ways of working in the software field. Sure. Kind of first taste of just getting code working quickly and then iterating on it was something that really started to take hold of me in the mid to late 90s. What were you doing at the time?
Building all kinds of different software, you know, for different companies. I remember doing a project for IBM, which really followed more of the Agile method, which wasn't called Agile. The Agile term didn't come until 2001.
get something up and running really quickly show it to them iterate on it make it faster make it better and and then put it out to production and that style worked really nicely and that continued with all kinds of projects from reinsurance company projects to like online commerce projects and things like that so you know really the entire process of iterating writing stories
the user stories producing acceptance criteria automating things and doing test term development or factoring you know all that stuff was just a big part of what i was doing back then For the listeners who don't know about you and Industrial Logic, could you just give a brief background on who the company is and what it's all about today?
I formed Industrial Logic after working on Wall Street at a bank for many, many years, and I thought, let me start my own company, and I want to bring the best of the best ideas from the software field to more teams and more organizations. So he was kind of inspired by industrial light and magic. That was really amazing in the mid-1990s with the stuff they were doing for movies that we'd never seen any effects like that before.
So industrial logic was, well, what are the special effects and the cool stuff from software development that we can bring to more organizations? So that was the inspiration of the name. And 1996, yeah, things were rolling along. We had Java in the browser back then. You know, that was a big deal that you could program there. It was literally... build these applets running in a browser and make them work for millions of people. So Industriologic has been teaching and coaching teams in...
Agile methods, lean methods. So the word agile has really gotten a bad name in the industry, of course. It has. If you're a software person, And you also have the Agile label on you. There are hardcore software people that just think you're nonsense because any association with Agile means you are a lightweight. And that's unfortunate because we are not lightweights.
And we are very committed to excellence in software craft and software development. But we also love our Agile principles and our Agile ways of working. And again, those continue to... improve, just like new tools come along that make things better, we have constantly seen process improve. The Agile Manifesto says we are uncovering better ways of working. We really are, and we are very, very merciless about...
dropping stuff that we loved once that isn't as good as something else we discover. That process of change, developing new practices, uncovering new practices, is actually something I want to talk to you about, because Industrial Logic... works with different companies to help them improve their software practices, deliver software. It's my understanding you all do a variety of different things for your clients, depending on the situation. I'm curious what practices you've developed.
in-house and then applied to your client work? A couple of things. One is sufficient design. So extreme programming really was saying merciless refactoring, for example. Be merciless. Decent advice, except that, you know, well, you create a commercial product yourself, right? You probably have to make decisions about what needs to be refactored, what doesn't. What's acceptable?
What's plumbing inside of your product and what's like really the the secret sauce the stuff that really makes the money Any software developers worth their salt could look at something I could improve on that. I can make that even better Developers love doing that. That's like a classic thing that developers love doing. Right. And so for me, over time, being an entrepreneur and creating our own, like we created our own e-learning product.
Part of the reason for doing that was because we love training and we want to make training really amazing. Part of the reason was I've always felt like we should be walking the talk of our customers. If our customers have products, we should have a product. Customers are dealing with...
this kind of technologies we should be using those technologies too and have our hands dirty so when we come in we're not just theoreticians no we've worked with this technology that technology back in the day it was a lot of customers using hibernate okay great we better use hibernate
Whether we like it or not, let's use it because our customers are using it and get our hands dirty with it. So building products teaches you a lot. It's taught me a ton. The e-learning software we built at Industrial Logic was just a... treasure trove of learnings. Sufficient design was one of those learnings, which was, I don't need to make everything perfectly refactored.
this upsets a lot of people they're like what are you talking about you're gonna have buggy software no no we test drove all the software i'm just saying that you can make stuff so gorgeous and so perfect artwork Artwork, you know, beautiful, gorgeous science. But wait a minute, that's just like registering students in the system. It's still enough. It's got tests. There's no bugs. I don't need to go further on that.
I don't need to polish the heck out of that. That's just plumbing. Well, so where do you draw that line? For a product, I try to look at where the money is being generated. What's actually really the part that's important? that makes the big difference and the other stuff is less important right is it something i'm changing all the time is that a high traffic area of the source code if it is hey it probably means that's important you better make it really excellent design
But there's a dial there. And is that dial at 10? Or is it dial at 7? Or where is the dial based upon the context? What I started to call that was sufficient design, which is sometimes it needs to be. excellent at a 10. Sometimes it can be at a 7 or a 6. It just depends on what you're doing. If I'm prototyping something, I don't care if there's code smells in it. I'm throwing it away.
Of course, we have to have the discipline to throw away the prototype. But yeah, I mean, the dial's way down. There could be duplication, bad named variables. Who cares? I'm throwing something together. I'm not going to mercilessly refactor. So, you know, it's a matter of... What is the context? And what am I doing at the time? Am I learning? Am I just validating an idea? Yeah. Am I validating an idea? Boy, I mean, my practices, my dials, I move my dials around.
If I'm putting somebody in production, it's going to be there for a really long time. It's really important. My dials are very different. That's something that came out of just building software. But also, if you put your actual money, your own money, into a product and you try to make money from it out there if you've got a natural product it's your own money what i say for a lot of people who are maybe a little too much in the ivory tower
because they've never experienced doing that. They've never put their own money, invested their own money into a product and seen the results of it when you're like, oh, look, we didn't make that much this month or this quarter. Should we do that really deep technical thing you want to go do or we want to go do that we're so dying to do? Or should we do something else that would help us make some more money? Should we invest that in something different, maybe marketing?
The balance of different things you have to think about when you really have skin in the game is just different. You look at something differently. It reminds me of a Jeff Bezos quote, focus on what makes the beer taste better. So now that resonates a lot. One piece of context I want to set for the audience, what's IndustrialLogic's approach to in-person versus remote work?
today, both internally and with client work? We ourselves have been a distributed company for many, many years. So really for us... Even COVID was not that big of a deal in terms of work because we have had people all over the place. We've had an office too where we meet in person, but the vast majority of our people are scattered around North America.
some in Europe, sometimes some in India, some in Brazil. You know, that's been just par for the course where we've been using different technologies. You know, we used to use VNC for many, many years for screen share. right um we've used all kinds of technologies for pair programming you know ensemble programming and we're constantly looking for the best technologies to use to see what we can you know do with our customers we've
Been doing a mixture of in-person and online help for a long, long time, long before COVID. Of course, COVID made it almost, you know, the height of COVID, it was all online. Today, whether it's training or coaching, we're doing usually a mixture. Some trainings are in person, some trainings are online. You mentioned that.
The team's been distributed for a long time, that you have a physical space that you get together in person. I'd love to hear how you think about that balance, getting together in person versus... collaborating remotely. Yeah, so we did close our office. We weren't using it, and we'd been there 15 years. It was just sitting around. It wasn't something that we wanted to keep paying for, so...
We actually meet at each other's houses. So for people that are in the Bay Area, we'll just go and meet them at their house. It's really quite nice. And it works for smaller meetings. It's great sometimes. go to a coffee shop or something like that. That's really, really important, I think, to get some of those in-person moments. But then, you know, quite a bit online, and we've done all kinds of things. We have end-of-year holiday parties.
One particular year we did a shared tasting where everyone was sent the same kind of beverages and we got to do a tasting of a variety of these little beverages and that was a lot of fun. I think it's important to have the balance between in-person and online. I think it's all online all the time, and you're always working by yourself in your home. That can get a little lonely. Yeah. What's been the toughest part about...
being remote for you personally? Sort of the spontaneity that can happen when you're in person doesn't happen as much online. You can try for it. You know, you can say, hey, I'm going to be in this room. Join me if you want. but it's not the same as just when folks come together i mean i've solved problems with colleagues at lunch where we're just you know we're in the office then we go to lunch we're sitting around joking around eating and then suddenly it's like oh an idea pops into my head
I've had so many experiences physically pairing with people. Totally. Or even ensembling. And there's something really incredible about that, you know, especially when you're... changing pairs frequently and rotating like that. There's a kind of an energy that happens. So you have to work pretty hard to make that same energy happen online. You can get pretty far online. I mean, you really can if you're creative and open-minded.
But people have found a new kind of balance in their lives with this hybrid world. I like being able to go pick my kids up at 3 p.m. at school and then come back and get back to work. I like that. I never liked being in an office where I could only come to see them at 5 or 6 o'clock at night. They like the balance. They like, hey, I actually can do my laundry during the day if I have to. Big deal. It's a laundry load running.
Or I'm eating much better than I ever ate before because I'm at home and I can eat healthy stuff. There's a lot of great stuff that happens with this new hybrid way of working. And I don't think that's going away anytime soon.
I just think we have to find ways to get together more regularly in person and make that a key part of our mental health. To me, it's not mentally healthy to just be alone all the time, even if you're on these... these video calls it was funny i was talking with one of my friends this morning and he shared a quote with me that was shared with him i think by one of his coaches which was
isolation makes smart people do dumb things. It reminds me of what you're talking about because there's this social emotional side to being alone and working remote that can have meaningful negative impact on the way that we work. And I'm not totally sure that we understand that yet. And so I'm curious what, how you think about Josh.
I'm wondering if there's things that you've noticed clients doing that you've been really impressed by to address this or anything that you do internally at Industrial Logic that is designed or set up to counteract some of the... more insidious sides of that loneliness that can come through. For some weird reason,
I'm very sensitive to those people who are remote. So I make sure they can hear my voice. I'm talking into the mic, you know, and I'm checking in with them and they're there. And it's always been something that for some reason came relatively easy to me.
I just believe that you've got to make that work because those people are valuable. They're remote. They're valuable. How do we make this work? How do we find a way to make it work well? And for a lot of times, that involves some kind of distributed collaboration. ways to make collaboration work. You know, because I'm so into social programming, and it's not like I'm some sort of major extrovert, right? I mean, I'm pretty much an introvert. I know if I need to get energy, I need my cave time.
Classic indication of being more introverted than extroverted. However, I'm also passionate about excellence in software development, and I've seen that pairing and ensembling lead to better results. So... I'm 100% on board with it because of that, right? This whole, let's do PRs because we need to emulate the system they use for open source software with complete strangers. It's just nonsense. You know, it's sorry. It's just...
bad, bad technology applied to this problem. It's unfortunate that the majority of people work in this open source way for what isn't open source. What do you think are some of the biggest benefits to social programming? Multiple perspectives on the code is a big one, right? And the design. So getting multiple perspectives in real time.
I think knowledge transfer is a huge problem, right? I mean, you know, it's if you only have one person that knows one part of the code and obviously the bus factor or the lottery ticket factor, if they win the lottery and they're gone. You know, nobody knows that area of the code. It's like, no, that's not good. People get called off for all kinds of reasons. If you're ensembling or pairing and rotating pairs, people know the code and we're resilient to someone.
having to go away for a relative who's not doing well or an injury or whatever the heck it is, a kid that needs help. There's all kinds of reasons people have to exit a team temporarily. You need a team that is resilient to that situation. And social programming brings that. It also is real-time, immediate code review. So you're not waiting around in a queue for code review sessions. Things just happen immediately.
There's just so many good things, even energy-wise. Like sometimes you don't show up to work with a lot of energy, but then somehow by pairing with others and on something with others, you get some energy, you get some laughs, you get some... enjoyment going and you're back in, you're there. So there's just many reasons why I think it's better. That's why we keep doing it.
For folks in the audience who maybe are into the idea of social programming, be it pair programming, ensemble programming, what have you, but haven't successfully tried it or want to try it with a new team, do you have any tactical tips or advice that you'd offer to somebody who maybe wants to give it a try? Get an expert who's done it.
to really do it with you for a half a day, a day, a little bit longer, whatever it is, get some extra help because you may think you know how to do it. I mean, back in the day, you know, when people were just, we weren't on something, we're mostly pairing.
People had no idea. How does it work? You know, what do you do with the keyboard? Does it go back and forth? And, you know, we were coming up with better ways to do it to make it more comfortable. We used to have two keyboards and two mice and two monitors. So, you know, it was like you didn't have to sit right on top of someone. You could have your own keyboard. There's all sorts of techniques. You know, when do you change pairs, all that stuff. An expert can help you through that.
and help you work through some of the more difficult parts of it. I mean, I'm a big believer in getting expert help. I'm a huge tennis nut, and my tennis game would go nowhere if I didn't... Work with great coaches who can see things that I can't see and help correct them for me and make my game a lot better. So I think it's worth that investment given that you may be doing it for long periods of time. May as well get good at it.
I mean, the highest performing individuals in basically every discipline all have coaches. And so if you want to be a serious developer or really a serious practitioner of any discipline, getting a coach, being exposed to coaching is... has to be on the list. I'm a firm believer in that. That requires humility. I mean, Atul Gawande, who wrote many books, he's a world-famous surgeon, you know, he wrote about this. He actually asked one of his old professors to come into the operating theater.
and observe him doing surgery so that he could give him some feedback. Even if he's a world-class surgeon, humble enough to think that maybe someone could help him. And in fact, they did. They gave just... tiny little advice, but it was the kind of advice that could lead to fewer complications for his patients, which is always going to be better. And yeah, that's what world-class robots do. We've talked a bit about...
different challenges that remote work creates or offers. And we're starting to talk about some of the different, more positive sides of software development or ways to improve. And I'd love to explore some... Areas or stories where the outcome was just quite positive. Could you tell me about the highest performing team that you've ever been exposed to?
I loved our team that built our e-learning software, and I was part of that. And that was distributed and in person. So it was a hybrid, totally hybrid. We were working in our office in Berkeley and also had people working remote. So, and you're talking, that goes back to like 2007, 8, 9, all those years, right? We were building the software. Google eventually purchased the software and we used it at Google in our trainings and then they purchased the online versions.
that we use there. Many other companies, big name companies have used it. Building that software allowed us to use it very, very quickly. We built some software for this kind of e-learning that we were evolving. and we could bring it into a classroom situation and just pop it up on the screen and have a few folks try it and see what they thought get some feedback you know try it for one exercise
Out of a course that's, let's say, three or four days, this is just like all of 20 minutes of time to just test on something. And then grow it and grow it and grow it. And, you know, we switch to technologies a little bit. We test drove everything. We switched from doing XP's iterations to eventually just doing continuous flow. So we stopped using all forms of iteration. We adopted a continuous deployment.
about 2010. That was so delightful, it was beyond belief. We were delivering about once or twice a week before that. So really for us, with our customers, it wasn't like there was a huge demand to do continuous deployment. You know, they're like pretty damn happy. They're getting releases once or twice a week. And that's pretty fast. In fact, even back then. But we thought, let's get our hands dirty with continuous deployment.
Let's do it. Let's really do it. And so we first had to get to zero downtime deployments, ZDD, be able to deploy without bringing the site down. And that was a beautiful evolution of our deployment process. Prior to that, it was fast, but it was still running a little script manually. So getting to zero downtime deployments was fantastic, which meant having blue-green kind of environments.
And then to complete automation, where you check in the code, and as long as it passes all the tests, and the build works and passes all the tests, it's live. And that was... That was amazing. Just absolutely amazing. So that team was incredible. And we were building both the e-learning itself and the content. So, you know, a lot of work on both. Both had to be great.
And also then providing the service to customers where rapid feedback on customer questions or any kind of issue that came up, we'd have to be really, really good about replying quickly. A goldmine of learning, put it that way. Just absolutely incredible. Yeah. What did it feel like to be on that team? First of all, I'd say that the people we work with tend to be very, very good.
I would pay someone a very large salary over having like six people that were more intermediate. Sure. Because if you get someone who's extremely good, it's not like you want them to be a hero. You're still pairing. You're still on something with them. However, they're just great, and they're great at so many things. They can be literally like debugging some strange asynchronous JavaScript one minute, and then like...
Making sure that something in C++ runs correctly on a certain Linux distribution. The next, I mean, like you're talking really deep technical skills. Profiling things, you know, just familiarity with like... a broad range of languages, tools, techniques. Even one person I'm thinking in particular was just frugal. They'd be like, you know, we come up with an idea and then...
Sometimes, you know, you discover your idea is going to be too expensive. And then, you know, I think programmers that don't think about finances would just keep going. People who are free would be like... wait a minute let's talk about this this is starting to feel like it's going to take many days maybe we should think about something different or you know what could we do differently and that's the kind of program i love is they're they're
thinking about the finances. If you're in a small company, you know, you must think about that stuff. It's not like you just burned cash. That felt great. That felt like, wow, you know, this is the kind of person that really is looking out for the health of the company. as well as the customers. So that person and then other people that you could just huddle with, we call them huddles, figure out what we want to build, talk about it.
riff on it, come up with bargain hunting. I'm a big fan of what I call bargain hunting, which is, you know, you need a certain capability for your users. But there's a variety of ways to provide it. To get there, yeah. There's the quick and dirty version that's not very fancy, but it does the job. There's really slick versions that are just uber sophisticated.
There's anything in between. You know, bargain hunting is like, let's try to find high value at low cost. What could we build that would be giving the user what they want, but doesn't maybe cost a fortune for us to build? How could we noodle on that? How could we brainstorm that together? And that's bargain hunting. That's something this team would do all the time and do it really, really well.
If you're in the audience and you're a developer who's looking to introduce a new practice to their team in service of trying to create that feeling that you were talking about where you can just tell you're on one of those really high-performing teams, what's a practice or two that you'd recommend? that they start exploring or tinkering with to help them take their game to the next level. I love to basically have them adopt...
a ton of stuff at the same time. So I would say I almost never adopt one or two things. I have had way better success bringing in an entire sophisticated way of building software from product to programming. From the beginning. Wow. See if they want to try that. It's like basically saying like, not that I'm a big fan of McDonald's or anything, but let's say McDonald's knows how to create.
get the food flowing very quickly. They're famous for, you know, inventing that style of just high speed and fast food. Well, great. If you want to help a kitchen become more like that, you could say, well, let's start with one thing. right you know or two things and the kitchen changes a little bit but if you bring almost the entire process in there i mean they're going to transform very very quickly
So in my experience, if people are willing, you can't shove it down their throats. Forget that. They have to be willing to experiment. If they're willing to experiment, I bring in as much as I possibly can, from chartering to story mapping to discovery trees to... story splitting and TDD refactoring CI CD as much of it as I possibly can and Get them doing all of it together. That's my much preferred style. That's interesting because to me that sounds like
much more like a Big Bang approach than an Agile approach. Can you reconcile that for me? I find that it's slower to adopt things piecemeal when it comes to how you work. It's slower. You get a certain change resistance or change fatigue. We took on that practice. Now you're asking us to take on another practice, and now there's another one coming. When is this going to stop?
Whereas if you get to experience something like nirvana, we would call it. Now these days we call it WOW, which stands for Ways of Working. Get to experience it. You might say, I want to do that. I want to live in that kind of world.
It's like you're habitating a new world where things are just very different. And the conditions have to be right for this, right? It doesn't work everywhere. You can't just snap your fingers and make that the way you transform every single environment. It's my preference, though, because... I've had the most success with that in terms of a meaningful change the way software is built. Agile doesn't say, thou shalt change piecemeal. I don't think Agile says that. Sure.
Agile wants you to move with quick, easy grace. It wants you to work with quick, easy grace, to be quick, resourceful, and adaptable. That's the sign of being agile. How you get there is up to you. You can get there in all sorts of ways. So I've just found that whenever possible, yes, trying to help a team dwell inside of a whole bunch of great software development practices is a lot easier if they just...
We used to call extreme programming a necklace because all of the practices were very, very tightly connected. You do refactoring better if you're pair programming. You do TDD better if you... UCI, you know, you're doing continuous integration. They are connected, so it's easier to adopt than to connect it up. So before we wrap up, I'd like to talk.
a little bit about the future and get your take on that. Software development practices are obviously constantly changing. Industrial logic has cut its teeth. teaching teams some of the best of the best. And you've talked about a bunch of these already here today. How do you see software development practices changing over the next three, five, maybe 10 years? Well, we're in this major AI bubble at the moment, right? And AI.
is likely here to stay um i do think that we're going to see a lot more specification driven development where you know you're really focusing in on what is the spat and then the ai is going to build the software Now, today we see AI building a lot of crappy software. The designs aren't really good. It's kind of scary how bad it can be. Building something out there. I was building a unit testing tool with it the other day. And...
I explained that the progress bar that goes across the screen when the tests are running wasn't working correctly. And it's like, oh, I can fix that for real. I'll do polling, you know. I'll poll the results. No, no, no, no. I don't want polling. Don't put polling in the code.
But it was just, it was ready to go do that. Yeah. With no judgment towards like, oh, but pulling is actually really bad. I mean, it just uses up CPU. It's a terrible solution for updating the progress bar. But, you know, it was ready to do it. It has a long way to go. However, I think it's naive to say that it's not going to have a huge role. What the role is exactly, we don't know. But if you're giving it really clear specifications...
Little ones, mini specifications, many of those, one after the other, to deal with all the complexities of the software. I believe we'll be able to do it in the future. The problem today is, you know, we do... We're all over the place. There's the back-end software, there's the front-end software, there's mobile, right? There's like all these different things, there's CSS, and it's a complicated bag of stuff for an AI to get right all across all those.
platforms and domains and things. That's pretty damn hard. So, in theory, in the future, it will be able to do stuff like that. Maybe we're going to have to simplify the ecosystem of software development in order to really get there. because i think it's far too complicated today so it needs to get simpler and i believe if it does ai will be producing a lot of the code and will be guiding it
That's what I think we're heading towards. What's your favorite AI code editor or writer? I mean, I mostly muck around in ChatGBT. I do go to some of the other ones sometimes. There's a lot of great stuff coming out now. I am partly wedded to the JetBrains. You know, I love the automated refactorings and all the things they do there. But I look at automated refactoring and I say, is there a future for this? Yeah, because this is handcrafting code.
Yes, it's using automation to improve the design of existing code, but are we really doing that in the future? You know, it's something that I love to do. I even submitted a conference talk recently called Joy of Refactoring, and I'm like, is this going to be...
Is this going to be like something that nobody does anymore? And why should I even be? Three-year shelf life on that talk. That's right. Yeah. Or half a year. I don't know. But I have friends that are basically saying that, yeah, programming is going away. And it's going away very soon. And these are people that are serious technologists who are building software for giant companies. And they're literally on the cutting edge of AI-driven software development. And that's what they're saying.
So it's kind of a crazy world we've entered into with this. Yeah, no doubt. Well, we could fill an entire hour with that. So maybe we'll cut it here. And I just want to say thank you so much, Josh, for being generous with your time and perspective, sharing your insights with us. What's one thing you hope listeners take away from this conversation?
Spend more time pairing and ensembling and do it in person, do it with remote tools. It's a far better way to produce higher quality software, even if you're going to end up... you know, giving specifications to an AI, you know, do it with colleagues, do it with subject matter experts, do it with testers, do it together and drive the creation of great software that way. So, yeah.
I love it. And if folks would like to learn more about industrial logic or you specifically, where should they go? Just go to industrial logic.com and find me under the people section. And yeah, I appreciate Jack. I appreciate you having me on the show.
Yeah, good deal. Well, thank you so much, Josh, and hope to chat again soon. Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.