Volume lowers the way people put together the delivery processes by guts and Instinct. So, how do you go up from there? I think the next step up from there is the East the data that comes out of the system to help you make the right decisions. When I say data-driven networks. I mean, like don't need eye on this Human Experience and let the system tell you we should be able to find out any information from data. Hey everyone. My name is Henry Surya be Robin.
And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal.
Hello, everyone. This Is Henry story of your oven and back here again with a new episode of the tech lead, you know, podcast, thanks for tuning in and spending your time with me today, listening to this episode. If you haven't, please subscribe to the tekhelet journal on your favorite podcast apps and also follow technology. No social media channels on LinkedIn, Twitter and Instagram.
And if you'd like to make some contribution to the show and support the creation of this podcast, Please Subscribe as a patron at technology, no dot f /, Patron. And help me towards producing great content every week for today's episode. I am very happy to share my conversation with Kazuki kawaguchi.
Many of you would have heard his name before, as he is widely known as the creator of the famous Jenkin CI, the most popular, see ICD tool used by millions of developers, and I guess it's still the leading cic, D2 by a mile. I personally have always wanted to have a chance to speak and interact with Kazuki. As Jenkins has always been one of my favorite developer tools since a long time ago.
When I started my career after his stint at cloudbees, Kazuki is currently the co CEO and co-founder of Lunchable a test recommendation engine that uses machine learning to speed up CI pipelines by selecting the right tests to run at the right stage of your development workflow. In this episode kisuke, shared about data driven, devops how to improve developers productivity. The future of software testing and why he created lunchable to help us move closer to achieve those things.
In the beginning of the episode. You can hear from Kazuki, his story on how he created Hudson during his time. At Sun Microsystems to solve his own problem of frequently breaking the build. I mean, who never breaks the build right, which eventually led to become Jenkins and the rest. Many of us know, is history. It was really a fun and great conversation with Kazuki and I hope that many of you could also benefit from this episode.
If you liked it, leave this episode of writing a review or comment on your podcast app or social media channels those reviews and comments are one of the best ways to help me get this podcasts to reach more listeners and hopefully they can also benefit from the contents in this podcast. So let's get this episode started right after our sponsor message. Are you looking for a new cool swag? Tackle, it Journal. Now, offers you some swags that you can purchase online.
And these wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting technology. No, dot f / shop, and don't forget to break yourself. Once you receive any of those tracks. Hey everyone, welcome back to another new episode of the package, you know, podcast today is guess. I'm so excited. I'm sure. Most of you would have been familiar with his name.
He is actually kosuke. Kawaguchi, one of the most popular figure in the tech industry. I would say, if you ever use the CI server, which is Jenkins. I'm sure, you know course. Okay. He is the creator of it when he was working with son, used to be called Hudson, and then, because of a few reasons, then it became Jenkins as a fork of Open Source.
And then kosuke fronted a became one of the most popular if still not the most popular CI server available in the market today, Kazuki also used to be the CTO of cloudbees company that runs behind the Jenkins that is supported for the Enterprise and also won a few Awards oreilly open source, Ward javaone, rocks toward Rakuten award, and things like that.
So he's very famous in this time because we case actually launching his new company and product, which is called Lunchable. I'm sure we'll be talking a lot about it later on so cozy. Okay, welcome to the show. It's great to have you here. Thank you very much perfectly. Give you more credit than I deserve. Thank you for that. Yeah, actually you are one of the person that I would like to have a chat because few years ago. This could be even decades ago,
right? I was so stunned by the Jenkins CI server. So, I was always wondering why this person is creating this project. It's so cool, and it's free. So, during that time when I started my career, it was really, really cool.
So really happy to have Of you here in the show ring to so Kazuki maybe before we start we would like to hear more from you about your career Journey. So, of course, there are so many highlights, but maybe in short, if you are able to maybe summarize your career Journey so far, what are the turning points and maybe major highlights for you? Personally. Yeah, so I grew up in Tokyo. That's where I picked up programming.
And then in high school. I started selling software made the operation did with the, you're in the college. And then after I graduated, You ate it. I think all involved in this schema language for XML is the picture that I want people to have in the head. It's like it's almost like a Star Wars movie. So there's like a standard body called that we see. See, it's like they're building a death star.
So there are the Imperial force. All the vendors that you for the energy, small bunch of idiots that coming together. They have different ideas of how to define skin language for XML. So they are like a rebel forces and I kind of got the clue to the into the river for side. I understand. Working on it and it because of that deviation. I landed in California to work for some Microsystems. Okay? Thing XML stuff a little bit eventually, the role of, I mean, that's how it always work,
right? The Empire wins. And then I started working more on the Java Enterprise editions. And that's when I started working on this software, you mention that they didn T become Jenkins, but the sound of the company kept going down, their business, wasn't doing very well. So I think it was nine or ten years. It got acquired by Oracle site experience, three months of Oracle. And then I left by then hot summers really doing pretty well. So I thought okay. Let's see. What I can do.
Is it so I could accompany became proud of these are we have a lot of fun and that lasted until 2010. That's where I had an opportunity to learn as a CTO and it was really my first experience of startup. That was a lot of fun and then I guess 2019 so shortly before the hole underneath Happened. Thanks ton of the company and then that's where I'm working. Day-in day-out, probably still office in California. Thanks for sharing. That it's pretty interesting that the way you working
initially on schema language. So tell us more like how did you end up working with Hudson during that time initially was called Hudson? Because see, I was, I think, probably still in the early stage. I think there was probably one other CI server available, which is called cruise control. What was the intention behind? Behind Hudson. So around that time some was a big company and in your big company. People don't seem to be working as hard as let's say.
They are in small companies. So they show up to the office. I don't know 9:10 a.m. And then like by 6:00 p.m. The office is completely deserted. So, that was Unthinkable from where I originally came from another world. I have a lot of time and then I did enjoyed writing programs. So it's like I have a lot of Open Source projects going on at that time. Hundreds of them. Probably.
In fact, I have this Vlog series called projects that they in an often created a koala little Library here and there day and a possibility, but there are a few other motivations. So one was that I mentioned that I was working for Java Enterprise Edition group. That's a middleware that someone's creating. It's a standard so that the other people can build application on top of it. It's a platform, right? And then realize that one day I
looked around and nobody. Well. Nobody might be too strong a statement, but the most of the He are working on producing that platform was not actually using that phone to do anything. So not seem like to go against the second including principal. So I feel like, okay, I gotta write some after these use a stack that our team produces to see if it's any good back, then, my day job, as XML and I was an engineering. This factor for people so team.
I used to be known as a guy who breaks deals because I help you commit some changes here and there. And then the next time somebody updates their workspace. I things don't even compile. So they did a little digging and pick up a phone and call me. Hey, they attach this file last time and it doesn't seem to compile so I can you check what's going on and sure enough? Like my change wasn't fully complete. So that was embarrassing. At some point. I got to fix that.
So I thought, okay, let's write some program that do that. So that it catches my mistake before my colleagues and then it just so happens that there was this CI software written in in Ruby or maybe title, but and I really like the way it looks like started using it. But Just didn't scale. So the moment I started putting a little bit more curl. It's a big crime was, I thought, okay, it, maybe I can write this. So that's kind of how it
started. Wow. It's really interesting because it started as a personal project to help you to avoid embarrassment of pregnancy. And actually the concept of CI is Elvis. Yeah, to actually detect that early so that the people either can refer to or fix the bill so to speak. So then once it becomes Jenkins, what was your contribution in order? To make it such a successful project. So why people are picking it up,
massively? Sure. So in the beginning like I was the only user and that went on for like I think almost two years I was using it in my team. And by the way that I discovered that I wasn't the only guy who's breaking deals all the time and everybody else in the team. Did. I just need to even notice those? So that was useful or they kept giving me this feedbacks. Maybe you can do this and that and that was really encouraging for me. So that kept me going by then. I knew he liked.
This theory about what makes this thriving, open source project. Then in my mind, that is the kind of guy the people's way. So, in other words, often people who want to participate in open source project has clear idea of what they want to do, like in the direction in which they want to take this project. That's really painful, is the comments of the people, especially the existing contributors in the project so that they buy into the idea,
especially the bigger candy. So I'm proving changes as a
general rule of thumb devil. A person more interesting, just doing things and convincing other people that do in the season, I think so. I thought if he can create this massacre technical architecture that enables people to experiment on their own and then build things on top of Jenkins, collectively as a whole, it still looks like changings and then if we deal the supporting social structures so that the people incentivised to bring those pieces together into one
place and kind of collaborate in some limited degree, so they still get the They still get back to the Kings when it comes to their plugins, collectively that we need to move to something Direction. So I implemented that and it has the technical Parts activation. But also has the social part that means maybe that got the key contributions and then we also the people started writing those. I also no longer writing a CI system. I was writing a platform that allows other people to write the
Cs systems. So that's how I can agree. So, in terms of the current devops eicd landscape, What's your view on this? Actually your personal view because it has grown so much since that date. There are so many CIA or cic D, tools available these days some are popular, some of like open source. I'm a commercial. So what's your view on the current see? ICD that whoops, landscape?
Yeah. So one thing that I find interesting was, when I originally did the Incans, what key role that we function as a place for the collective trees. So, in other words, like it was used as a means for People in the team, the be on the same page about the state of things, the distance successfully land is this trespassing or fading.
Now that the think I mean, it isn't 20 years 21 talking about these things you like crazy, but back then like these things involved a phone calls and emails and stuff. That's often. There's the time delays and stuff like that that made it difficult for people to be agreed. Whether this problem that they are seeing yesterday has already been fixed or now. So in that sense, s CI server was Not visible.
It's almost like a billboard that the people would go to see and then I think over the last 10 years the solar completely flipped in the other directions, very evasive. If you like, it's almost completely invisible. Maybe the only interaction people have visit is when they're fully cast gets this a green checkmark the we good to go or not. Yeah. So that was a surprising change for me. So from there, I think about two things. The one is that when it's invisible, you can go up a lot
more in the complex. Sophistication. So to me, this is actually opportunity when people need to understand like what those things being there means you can't really go too far second automatic transmission in a car like it still makes you feel like there's a distinct gears that you'd be shifting. But then this Technology Innovation happens like a continuous variable transmission completely, get rid of the notion that year.
So when your automated you can take on the second next develop like Evolution and that's something I think about a lot. All that's probably like, what eventually became intelligible other part of it is I think there needs to be a little bit more on the push back like a swinging back until serving useful information to the developers.
It's the reason you're running these CI processes so that it catches something and then informs the Mopar to work on something and then when that's the used to just basically a Colombian information, I think there's a lot of opportunities lost. So I think there's opportunity for us to do things better. And that's where I see the CIA. System currently. Yeah, I agree. Like Ci server currently is more like a transparent system.
Hopefully, everyone has been running CI server for building their software and it became part of the norm. I would say, in terms of software development. I think one of your passion is actually about developer productivity, right? So in your view, what is the productivity? Yes, I'm thinking, mainly from the anglos, if I'm a leader of a team, then I'm thinking about, you know, I have a set of people with different skill, sets and different. All of experience and service
stations. And I need to rise all the boats in the make everybody a little bit more productive. So arm them with more something like more information more power. So that's the angle that I'm thinking about the eventually that got some became one of the key driver for me. So that was not how I studied it. But as he got used inside the organization's, I started thinking. Oh, so what this is doing is helping Junior Engineers to be more effective just a little bit and it's all like this one
software. It's going to make them twice as valuable, but I have very only the contribution going there. So that became the important part. Another way. I think of this is, you know, in the movie Alien, who's the lady? Sigourney Weaver? Yeah, so she's actually right into this power loader and then she fights is the idea. So I think of those like, what the CI system or this develops in general is doing, is that kind of like our mean, the humans, like amplifying?
Their muscle is amassing power. So it's almost like exoskeleton. How to do more with less. That's I think is what I think about the developer productivity and we are just basically trying to create more seatbelts because like we can turn that to change
this as fast as we want. If you don't care about whether it works or not, and then it's like a Everlasting challenge, I mean, testing is a part of it but it's also just one part of it. And there's so many other layers that we did ion to build confidence to the change. That's kind of developer productivity. Yeah. Yeah. I like the second. Go. I wasn't thinking it that way. So creating seatbelt or maybe guardrails, so that you are also productive. But effective, it's not like productive.
As in like churning a lot of outputs, but also the right output. So I like that definitely. So as a developer maybe from your point of view because you have written so many code in open source project. How should one be conscious about improving their developer productivity. We talk about Enterprise with CI server and things like that, but how has individual? We should be concerned? Yes, about improving our
productivity. Yeah, so when you frame it like that productivity, as an individual, it almost feels like how can you grow or like, how can you become a better engineer? And I mean, I can talk about that. But before I get there, I guess a more like a narrowly, this developer productivity. As I discuss in terms of like giving the same person.
How can we do more? I think the kind of key thing for me is demand that you be on demand TV of From the organization that you need the exoskeleton the power loader, I guess that we have these Tendencies and I did, I did to build my own tubing. We know because we can and they trying to do it, we tend to just before the roller wrong, instead of spending money, those money that we are spending is not even
a wrong, right? So, but me, a long time user of IntelliJ because the one do my hero program or was using it and that I picked it up. I think it was like for her. Million bucks per seat or something back then. And I thought, gosh, this is so expensive. It's ridiculous. So I refused to spend money on it, but then I can later, I became CTO and like, salespeople that the salespeople, every one of them spend $150 a month, the sales force to get anything done.
Alrighty is 100 bucks for Perpetual license back then. I mean, right now, I think they changed it subscription, but back then you just pay once and then be done. I also deeply I didn't want to do it. Theme music, that's silly. So I learnt a lot by writing code maybe more. So by looking it back in a few years later and not give each one's work, that chance didn't. So there's definitely like the body in time testing things, more. Generally.
I think it's the idea of retrospective when you do it with some intentionality, do it with some hypotheses. I'm going to do it this way this time because I think of X y&z normally open people don't think about those things and they just do it because they I feel like it without those theories and hypotheses and retrospect. It's critical to don't know how you did it. So to me, that's the key thing.
Like intentionally trying a different API design style, like the desert work, or they can working back for, what are the assumptions that I made in doing it this way? If you did actually hold or not. So someone pick a mindset almost, I think that's important. So, another thing more often than that, in the context of work engineering work is more like a finding the right balance or compromise. You don't want to waste
quote-unquote waste. Like the our is looking into the something deep and you can find a the program in 15 minutes. So that Balancing Act is important skill, but I also find it useful from time to time. Just go deep time. You decide to solve the problem, the hard way, and then go solve it in some sense. I think it kind of grows the muscle. Sometimes there is no easier way out and you have to go straight. Maybe like no matter what obstacle is being able to do that, when You need to, I think
that's really powerful. I'm sure they all have this feeling of this spend three hours debugging, and eventually only find the command line that needs to be changed, not always, but from time to time, I think it's a good thing kind of Li the communication and influencing others back. Then, when I started working for some programming, a much more individual activities with Italy had this whole system and a split it up in like a 303 ways and different people generally gotten code own. Parts.
They did the thing that way, they wanted around the interface. We Talks by to do things, but that was it. But now it's a lot more collaborative activities. I think the communication skills in the engineering become far more important. Thanks for sharing your personal view on this. I'm sure the reason why you launch lunchable. It's also partly to improve this developer productivity.
So you mentioned something about testing and lunchable is actually some kind of like that tooling armed with machine learning model in order to be able to To predict something. So maybe you can share a little bit more. What is lunchable especially for people who haven't heard about it. Yeah. Thanks. I want to start with what we do today in terms of function software and then where I'm trying to go, because the latter is much bigger than the former. So I was working on this Jenkins project.
That's the project that's being alive for a long time. We have what 18,000 torso, test cases every time I make one line change. I have to wait for one whole hour for If that's the path and then somebody comes into a cold baby, maybe he doesn't like the variable name. We make some changes and then another whole hour of testing cycle before I can land this change into the master Branch.
I find that quite painful. It's good thing to have a lot of tests that in fact changing a small part in your lord system. Then I don't think running all the tests are actually particularly meaningful. There should be a smaller subset of the Fest that it'd be pretty. Effective in catching any deviations that I might, cause that's the reason we have a smoke test. The idea of the smoke test is you have a big test the that takes like hours to Ram.
So it's great. I can really small subset and a power. I don't know if any of these tests failed and it's probably not even worse the tortoise. So that's another way of saying, okay, sometimes the subset is useful. Then smoke test is usually like a fixed manually, curated set of tests. Actually, if you think about it, it's not probably York tomorrow.
So one way to think about what mountain will is eating is so we look at the changes that the people have applied created and then we look at both the tests that you have and then we can make a prediction that okay? For these 10 days. You should be running these tests in this order to maximize the chance that you get, the idea right away, right off the gate. And then depending on very easily that can be used differently.
If you're using it for the pull request and what that means is the chances of you're getting the idea. Right after the 8, the right after creating a request comes up, so you don't have to come fix it into something else. You can immediately start working on the fix, and then preach another change and then welcome it. Double more quickly. Iterate on it a lot more quickly in other places. And I mention that govern our test is bad, but you have actual real-world software project 1.
Our test could be actually awesome. I've seen a full cycle test. It's going to take seven days. It's ridiculous. Let's imagine, like, you find one bag and you got it. Through the neck. You need to be done the whole test cycle again, like he can't even do it. And then those are still happening. I'm sure like a volleyball Diaz. Knows the project. Just like that.
So making those spaces money. If you can tell people like, okay, these are the tests in order to get 95% of confidence that this test changes duration fee. And we only need to run like a 15%, and we can be precise about these things and that's what we do in terms of a. So now if I'm a step onto the where thats from the deity, This is, in some sense. Just one quotient chord, minor optimizations. And I'd actually soft migration because Nate's, a personally painful thing for me.
And I know a lot of people suffer from it, but I think of it, I guess essentially a guy self-tuning delivery cycle. Like I talked about how these stick shift evolved into automatic transmission into continuous variable transmission. That doesn't even have a year ratio. Thank you, something similar. If you have this automation process going all the time producing data and Gave you Earth in a system itself, should be able to use those information. First. You can inform people better in
a second thing. I can make the whole delivery pipeline self-tuning. I'll give you some example, we talked about the second one bit of information from the CI system, you get sometimes failed. And so, it's something fell. What is going to be? You click the link, and look at how it feels like you have 5 beta test cases. Now what you want to know? Okay. So severe of these failures. Actually like I've known to be a flaky test like we do, I don't
have a flaky test program. So if somebody can tell you that, by the way, these three phase is probably not worth paying attention to because they feel the same way left and right, but these other two are more interesting because those are new. So those are like an example, contextual information. And then we told our little bit like, a small way, is that makes it productive. So you make some changes and you break. We must enact a dozen, different test cases because you know you
update the system. You need to update your test code and it kind of begrudgingly do it because we all feel naked. About the karate, right? So like who am I to seal away the test but are all these test cases actually really useful. We kind of ask them over time and I don't even know what this desk is testing this. And that's going to take the fashion to make it pass. When you add more tests on the road. Maybe are they overlapping?
So there should be some critical eyes to let's say that return on investment every test case as incur, some cost in terms of execution time in terms of the maintenance and all that. So easy. It actually producing value to justify the cost and we should be able to get those information from the system itself that we don't say, that's kind of like the complex information talking about. Now. If you look at the whole day of a pipeline, it's not even. Just like one set of tests.
He's like, you have a different test seat, or maybe sometimes you have a different branch marketing, strategies all designs. Those are the seat belts that we talked about it in some small things. Like a naive thing is like everybody is creating up to request and they get theirs. Didn't land into the master in a larger team, it actually breaks down. So they need to have Team level integration branch which sent
this a landing. And the second level of integration that I've seen those places and then they'll test unit tests that run quickly. So you can run it very close to the left side of the development cycle. Very close to where the cotton happens. Some of the integration tests can only run much later because it takes five hours to that. We can only run it every night. So, all these PCS, the build guy. It's going to go in and okay, we're going to do it this way.
I'm going to put this test here to run it every night or maybe every week, something and then that's it. And then once that's in place that stays for years because nobody, they are see touch it. But of course, like there's a project become speaker or changes. What's the optimal strategy to do the merging or Verity run? The test actually should change. So you run it every day. Is it decorative? I need every day or is it better to run it every 12 days so that we have extra cycle that can.
Used to run different kind of test. Now what's optimal? So people are not actually be intentionally making those decisions and so the step by if he can make it, those ition dated Regional waste and then if you can further step up that decision like leave those efficient machines, that's the world that I want to get the I can definitely relate to some of the problems that you mentioned. One line change. Like whether if it's just a, it's a string, right? It's like it's harmless like a
string on a label or something. And you run through the whole cycle of the build and you wait for that until it finishes. Only then of course, you are sure that it will pass anyway, so I understand all these things that you mentioned. But how do you integrate lunchable where exactly that Lunchable is actually triggered and how does it help over the time to actually make this kind of prediction or judgment for you to tweak? And then what you should do
afterwards. Maybe you can explain a little bit on that side. Yeah. So the key to make it universally useful is the video. The increase and as much as possible. So make the surgery yet small as possible because I know how scary for some people to be modified is like a delivery pipeline. It can feel like a snowflake. So it created the second, very small open source, command line
tool and that's your agent. And then the first thing you do is going to be building, a binary, you're going to tell us. Okay. Here's the source code that's camera turned into build. So otherwise known as video materials. What went into this program like a git? Commit basically. Li now at some later point when you run the tests you want to tell us. Okay.
These are the 15,000 test cases and thinking about running and the software that I'm going to test this field and others are still kind of point that back to the idea bill of materials. And then we're going to tell you, okay. So in that case, another parameter is what's your goal? So maybe it'll let's create a cleaning minute subset of the tests or there are different ways to say hello. And then we're going to say, okay. So in that case, run the test number one.
It's 7:20 and blah, blah, blah. And then we give it in the form. That's very easy to pass into the test Runner. You might be using, I don't know, like a maiden or nose or like every programming language has multiple test run or so, like, it's incredible number of those. But usually, it is test tools are capable receiving what tests around because developer needs it interactively. So, we use that may kinds and controlling the substitute test.
And then, after everything is said and done, we need to see how Oh those tests have behaved. So you point us to these tests keyboards that usually J. You need files, this de facto standard XML report format. And then we look at those to see. Okay. This test has man and think about .5 s has failed and that about a bra and everything, like a floor of those, the information, on the other hand, the internet on your side and we crunch those numbers. FEI tomorrow.
Our brain, the be a little better so that we can make a little better prediction. That's how it works. The imaginable. Language and testing framework, is this to language-specific like title specific programming language? For example, we have also multiple layers of tests. Just like you mentioned, you have units as functional tests, may be UI test, security test, performances, can this be tool used for all those tests as
well? So no, it does not depend on any programming language and yes, it can be used with any tests. So, quite intentionally I decided that at least right now. I know going to look into what's the source. Code and how its structured, there's some tools and some approaches in which people pass this.
Let's say the Java programming Java source code in the bill to syntax tree and try to do this, almost like a code analysis based approach or the called coverage based approach, but that's going to be said, not really make it a programming language. We have this incredible diversity of how we do things. It's actually a program. It's really a problem. But that's the reality is I wanted to make this University applicable because the king
Clarity problem is universal. And then the flip side of it is I think it's missing some you know, like I'm fading to exploit some performance efficiency that the machine learning can do. But right now frankly squeezing like the demeaning last 5% of the performance isn't my concern. I think it's the idea that something like this is useful that we should be leaving more control to the machines.
That's the idea that we need to educate people and people need to pick up. So that's where we stand. And then same thing about this. The phase of testing your right leg, maybe do anything from unique testing. The API testing to UI testing the whatnot. So the general idea is that you have this thing. You're testing that can be attributed to your set of source code the building materials. And then you have this thing called something that runs against it and produce you.
The binary result pass or fail, then we can fit into this mold. So that's why we do like a unit Test. Example, people tend to run down a lot so that produce a lot of data and more data tends to be a better. All the ill. So and seeing different performance. But and that is also true from one product to another right now. Yeah, you can take this tea, anything and then let's see what it does in your project. I mean certainly it will work nicely with the software that has a lot of tests.
But what if the software has very little test, I'm sure there are many software these days. They don't have enough test coverage. Yeah. So there's a whole other area of quality affordable. You said for custom automating tests. I'm not Catfight automating is hard. So I expect that to continue, but it's also the automation is a very fragmented field like in the browser automation requires, one thing. Mobile automation.
It's a wholly, different game and if you're trying to automate the testing of a video games that Center be another thing and then so on and so forth. So again, it's really hard to build anything Universal in that space. Yeah, so I leave that fight to these people and then when you start back in late, more tests. Now you have a From program and then that's where we can help you. Right? I'm sure you have a number of customers who have tried and used lunchable.
Maybe any particular story that stood out for you that you can share with the audience here. How long you will actually help that customer to improve their productivity or their testing cycle? Yeah, so I went through this conferencing puzzle con. So the buzzer is built to that came out of the Google. It's an increment of your test systems. So When people have the second massive software, they build and test takes a long time. So these people did I turn into these tools.
Now changing a build tool is a huge deal. In facts. Everybody's working Styles. So like I say, bother calling is a place for all the users. I guess the key users of the puzzle that comes together and stop there. No, it's someone of the presentation. There was a speaker was saying
also in this company. We assign for engineers working on. Two years to take on this project and we are almost done, but it's still going to take half a year or so. So I was shocked to hear, God's sake, spent eight money years back in of the good Engineers. This build guys are lollygaggin ears and you're still not bam. And then the first guy who stand it up to the questions and all, that's amazing. You did it so quickly though. I was a trick and I was like, probably Shock Vac what's going
on here? This is not the time frame that I'm used to. So, you know, yes. I'm thinking legal in touches that those guys and then they introduced us the another team inside the company. And so that we started working installed. So in some sense like this is not either or most of the time, especially in established project. These people are in between a rock and a hard place has to
keep things running every day. And then it's difficulty that increment to be squeezed a little bit more value speed like whatever I love it. And you know, your test Hardware combination might they are doing embedded development. So tomorrow like a new hobby or a type error. It seemed like the best overload. Like the increase is I multiplied. So they need these immediate help to get stuff under control so that they have Cycles. Induction take on larger longer
project. I think they see us as this kind of here is to buy more time because when you're running a subset of this, you don't really need to change anything fundamentally different. You don't need to spend for engineers working on two years before you start to see any benefit. So that was another experience and as the can other on the totally opposite end. The Spectrum there's a team of two Engineers working on the web service and the testing cycle is spending minute.
So like a far cry from one longer unit tests, but he has a lot less to frustrated. 20 minutes is a difficult time. If I'm telling you that your next meeting is going to be in 20 minutes. All you're going to do what can you do and it's too short to work on something new. So it's like adjusting this like a year or next month. So you're able to cut them down into think 11 or 10 or something. It's got half. So he really liked that that creates this much rapid cycle.
He doesn't need the compact sweets as much even said, goodbye allowed him to write more tests because like previously he does very that every test. He is as it's going to add to the time. So now as I be motivator, but now he doesn't have it. So that was a really great story for me. So you have been dealing with this problem since I think last few years about software testing. So what do you think the future of software testing? Like tools like this. I think this is probably one of
a kind. I haven't heard such tool before like I know about basil incremental build. Like it doesn't build at the whole software. But to test only a part a subset of your test cases. I think it's still one of a kind. So what do you foresee the future of software testing going forward? Yeah. So there is a, I think two things going on. The one is ensuring quality became a lot bigger than testing. So that's unrealistic. When years ago, we are shipping packets of Lion's.
Share of the quality came by running tests and making sure that things are good before you shit. Now, for the most of the people, that's not how we ensure quality. I mean testing is still a key pillar, but now we have other means, like feature Flags controlling doing a smarter row, light using monitoring tools like the failures before, too many customers gets impacted. I feel like there's more defense in depth. There's all sorts of factors combined like eight of them
designed to reduce the risk. Accepting the fact that some bad stuff is going to happen. So I think there's a lot of that going on, more of that. It's going to happen. And then narrowly on the testing side. I think what needs to happen is focusing more on the increments. Again, some was in the business of selling this packet software and then we are releasing it. Every maybe once in three months or major. The Beast is everyone's two years and then minor. It is like every six months and
then party. Thus every month or something like that. Then that kinda like a timeframe. We still operate on. So then, having a full test cycle that takes two weeks. That's kind of okay, like, it's been formally. Doesn't manageable like you're trying to shift every day, like the ploy every day. You cannot possibly have the past two weeks, but the amount of tests that you are masks could easily run up to those. So, I think the way to make this work is it's almost like movie frames.
If you look at the real stairs, a 24 frames per Or second or something like that. One frame to the next is only going to change a little bit. But if you try to inspect every frame thoroughly then, yellow want to have enough time. Maybe we can do is a common frame per second.
Not 24, 30 DB creates is not show up for limiting, higher frequency than you do. So, I think the right thing to focus on is not to look at one frame in the movie, but look at 30 frames in the movie and compare the difference. Because if you speed goes up, The building is going to go down. So I think that's the change that needs to happen. Some people doing it crudely like in a hotfix. There's a different process.
Some things are different process for hot fixes like this expedited Lanes. That's like, very good way of. Well, the hotfix is small so it should be able to do something small to put that into production. So it's the same thing and I don't think they're doing it consciously, but that needs to be Point braced became more. They do things. Yeah. I mean like hot cakes. Yeah. I must admit I do. Also have this kind of high-speed Lane where you probably don't like the whole
test. Sometimes even you are so confident that you just deployed in whatever so I can see definitely with tools like this and hopefully in the future more and more such tools available. We can improve this kind of hectic way of doing the software deployment. So I think that will be great. Definitely. So I saw a another talk that you gave maybe few months ago is about data driven, devops, right? So, what do you mean by data driven here?
I mean, I talked a little bit about high like a basic official manual transmission. The automatic, the continuous variable transmissions on my titties is by and large the way people put together the delivery processes by guts and Instinct. So, how do you go up from there? I think the next step up from there is the Easter data that comes out of the system to help you make the right decisions. Is this test failure of the key and they experienced person who's being these products below
and already knows that all. Sometimes it felt. Us in that way so that it's a tribal knowledge. But I say data-driven networks, I mean like don't rely on this Human Experience and let the system tell you we should be able to find that kind of information from data. So that's why then I gave back a few story. So high, the real world team will be able to do something seemingly very small and easy and still managed to get a lot
of value out of these airports. It was one example, the guy doing a regular expression pattern matching on the last x lines of build log. Regular expression, of course that has to be like the tool that we bring in. So it's almost got this like a smell of Backpage solution right
from the beginning. So depending on her staff failed, if the infrastructure failed, if the CIA build testing infrastructure fail, then you want to notify the CI team, if the failure is due to the application called or the test failures, even or modify the application Level first, and then, like nothing is worse for the c18 for the app developer still get notified. The failure of the c18 because
it really hot security. So he wanted to defend his own playing against this and probably be effective. I can totally see that. So those are all that great example. In my mind about how are you using data to make a little bit improvements here and there I'm not trying to talk about it like a number of to request for the story points. I'm sure those are good for some things and that's all. I mean, but it's more the Tactical improvements we can do. So, that's the kind of story
behind data-driven. So for those kind of scenarios then how would you actually collect the data? Because yeah, it's not integrated most likely into our tools into our software development. So how would you try call this data and actually use that to do this retrospection and also improve in the future. Yeah, so lucky, we are not the only people who are suffering from the the program. The whole world is going through the coat and coat the Big Data thing.
And so there's a lot of people building is getting data from whatever. /, Marketing sales, Etc. Customer interactions. And then try to extract useful knowledge a little bit. So we, since I will trade it space, lots of the isolation and I've seen number of teams over the last decade. They built their in-house Solutions. You can spot. Those. Those are like a dime, a dozen.
If you ask me, then this might sound really selfish but that smells like back in the days where every company was building their own CI system, because they needed it, but it takes time. Him trust me, you're going to do it. So I think that's a sign for me like this more. General solution. Is that beer? So that's part of the motivation for me doing on table. It's clearly that this is a universal problem and the people solving it on their own. They should be able to do better than that.
So for people who would like to learn and use lunchable. Is there some kind of free tier. Where do they play it? Actually? I don't know how to run this launcher. But imagine this a CLI. Is it like running on local? Yeah, so if you want the long table inc.com, you can sign up and get the API key within 15 seconds. And then there's public documentation. And as I said, he only in certain that this V things in your CI, scale to get this going and it's free for open source project.
It's also free for small teams, and I'm trying to work on building like a playable demo because the thing is like, before you can start seeing the impact in your product, and takes a little bit of time for data to your class. So, I have this second point. Project. The idea is like you go ahead and create a request to destroy product and we'll show you that it's going to pick up the right test. So I'm sure it will be great if it's integrated to open source project.
And you can see over the time actually because open-source normally has a lot of contribution, especially the most popular one. Of course, probably, it's a good way to demo the capability of the Lunchable, right? Yeah, exactly. So kansuke. Thank you so much for your time before we end the conversation. Normally I would ask one question for all my Guess which is about three technical leadership. Wisdom for all the listeners to listen from, what kind of
advice, would you give to them? Yeah, for this other interesting question that maybe pause a little bit. I think most technical leaders. They are starting point is like a leadership by called, that was the case for me. You just like the better code more quickly. And that's like how you influence people around you, and that's great, but it actually only carries useful for you, might be able to do it a casita instead of Maybe 10x better. But by the time you need to influence 10 people.
Like you 10x better coding skills, become a wash. So I felt like I struggled a lot from jumping from that to the next. So I think Nico has in that fundamentally. Not a scalable enough ways to make a difference. I think that's fun and to open the sky people as like, a sphere of influence. The way as I picking the leader, you influenced other Engineers around. You is you make an impact by influencing people. Around you. In some sense. They don't really need you.
They get things done in their own ways. So what is the body that you can add? One thing that I gravitated? There is like a power of Storytelling at one point in Kirby's. I made it my job to go out the software development teams and pork see how they do things and their struggles and create a story almost like in that Port late of their lives and then I bring it back to the company. The idea here is I want to help you man. Every picture here is problem,
you're solving. And then also hoping to get you excited in solving those people's problems. If he can paint a KSC, your customers picture. It's like it's always better than my car. Trying this. Help the abstract set of people. That's a power of Storytelling and I'd like to think it made some impact and then changes how people do things a little bit differently. And that's like all you can hope for but those things are much more scalable.
Like I can write this one piece in a few hours and it gets read by. By 200 people so. So coding, it's difficult, but the writing more presentation, similar, and then along similar lines. Started thinking about empowering more individuals. So you're trying to do something by yourself is useful. But again, we'd only scale so much at some sides of the organizations, like it becomes more efficiently spot people who are trying to do the right thing and then send more Spotlight and
resources. And I can tell people Okay, this guys doing awesome things, that's helped them so that I find them in some of the rewarding too, but more effective dollar. Other things that I felt like it's more smile. Yeah, but those are pretty good. I really like the storytelling part and also, like putting the spotlight for good behaviors that you want to promote within your team. I think that really resonate with me as well. So, thanks kansuke for this,
lovely chat. So, if people want to find you online, they want to connect with you, or Learn more about this launch, a product. Maybe where can they find you online? Yeah, so course, cable or is my website and they're all the can kidding sir available. I'm to boeing.com is our company website and their own Twitter, Facebook, Etc. The same as the company and Jenkins is also well. So yeah, that's how you can find me. So, thanks kansuke. I wish you good luck with lunchable.
Hopefully, one day I will be able to play around with it as well. Thank you. Yeah, and then we can forward to You're going back to Singapore at some point. All right, cool, then we'll see you. Bye then. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better. You can also find the full show notes of this conversation on the episode page at technology. No, the death website. Putting the full transcript interesting quotes and links to the resources and mentions from
the conversation. And lastly make sure to subscribe to the shows mailing list on technology, another deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.