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.