Ep. #16, Test-Driven Development Demystified with Jon Jagger

Eden Full Goh: Hey, Jon, thank you so much for joining me on the How It's Tested podcast.

Jon Jagger: Thanks for inviting me.

Eden: Yeah, so I'm really excited to get into it today. I was checking out what you had built with Coding Dojo, saw a couple of tutorial videos about it, but would love for you to share more with our audience about your background, what you're working on today, and what inspired you to start Coding Dojo.

Jon: Well, I guess the first thing to say for anyone listening is the name of it, it is a Coding Dojo, but there are a couple of them on the internet that you can use.

The one I built is specifically called cyber-dojo, and there is a story behind it. I was doing some work in Oslo in 2009, in November. And at the time, Bob Martin was also doing some work in Oslo quite coincidentally.

And as is often the case, the local tech community asked him if he would do an evening meetup, and he agreed. And at the time, he was very interested in Coding Dojo, so he did one at a local pub, very famous pub in Norway called The Scotsman.

And I went along in the evening and there was maybe 30 people there. And he chose an exercise which was battleships. And he chose a language. I forget which language it was. And he chose a test framework, and I forgot what that was too.

But then we've split into groups, and the idea was that everyone would code for probably at least an hour, and then we would reconvene and everyone would show... The different five or six groups would show the work that they'd done.

And what happened in a nutshell was that when we tried to reconvene for everyone to show their work, there were a couple of groups that basically had nothing to show because this was 2009 and they were still trying to install the language that had been chosen. And remember, on a pub wifi, remember-

Eden: Oh no.

Jon: And the ones who did have something to show, there was at least one of a MacBook that was trying to present to the projector, a Linux trying to connect to the projector and a Windows machine trying to connect to the projector.

And the usual problem happened there. I mean, it's a lot better than it was in those days. But in 2009, again, I can imagine, you can guess what happened. Then we spent a ridiculous amount of time trying to just allow everyone to get connected to the projector to show their work.

And so in all honesty, it was a little bit of a fail. But I was in my hotel room that evening, thinking about how could it have been better? 'Cause that's kind of my nature as an engineer when there's a problem, it's quite interesting.

And so I was working through my mind how could you implement something and design something that would basically solve the problems that existed there. And I realized that you could solve both problems with an online Coding Dojo.

Because number one, people wouldn't have to install anything at all. They'd just be doing everything in their browser. But more importantly, you wouldn't have to connect multiple laptops to a projector.

If Bob had cyber-dojo, he could have connected his projector while people were doing the work, and it might have taken him half an hour to get the blooming thing working, but so be it.

Once that was done, he's connected and showing all of their work because every time they do some work in the browser, it's held in the cloud and we can just show everyone's work whenever we want to.

So that was the genesis of the idea. And there's a couple of times in your life when you get an idea and you think, actually, that is a really good idea that I would actually like to commit to in the sense of really committing your time and your effort to do it.

So that doesn't happen very often, but it happened for me at that point. And I really decided it was a worthwhile project for many reasons. So I decided to build something to solve the problems that Uncle Bob had experienced that evening in November in 2009. So that's the genesis story.

Eden: That's very cool. I remember being really impressed by cyber-dojo when I was looking it up. The idea that you don't have to deal with installing the framework, you can just open the browser, a new tab. It really reduces the barrier to entry.

And I think for a lot of software engineers, there is that initial upfront friction of, "I just spent all this time trying to set everything else up. And this is just yet another library that I have to read documentation for and install and set up."

And so you're really reducing all of that friction as much as possible to kind of teach the right best practices to engineers.

Jon: Yes, that is definitely one of the big factors, as I mentioned.

It's fair to say it's a lot more friction-free than it was in the early days. I have done a lot of work to make it as good as I'd like it to be if I was someone who was actually participating. But yes, the two key things are that you don't have to install anything whatsoever, both in terms of languages or test frameworks and the fact that everything's on the cloud.

Well, actually that's a good point because it's not just... There is a sort of a backstory there in terms of the philosophy, if you like, of cyber-dojo.

Eden: Yeah.

Jon: Because if you think about that situation where Uncle Bob is showing the work that people have presented, how do you do that?

The classical way that you would do it is perhaps with the different groups logging in, someone logs in. And when the work is shown, you could imagine, at that point, you know who did that work.

The person in the audience is Bob, and we're showing Bob's work. There was a little group maybe with Bob, but we're showing Bob's work. And then there was someone else in the audience called Kathy or whatever, and we're showing her work.

And that's possible it would work, but I didn't do that for two reasons. The first three smaller reason is that I just wanted to, again, like you said, avoid the barrier, the friction of logging in.

Eden: Mm-hmm.

Jon: You don't actually need to log in to get started, which you don't have to do, as you know, in cyber-dojo.

But there's a deeper reason and that is that if you don't log in and you genuinely don't know whose work you're showing, when you present at the front, again, imagining your Uncle Bob showing this different work, then you can't sort of say to whoever's in the audience, "What the heck were you thinking? This is terrible." And actually point to an individual.

Eden: Mm-hmm.

Jon: It's completely anonymous. And I think that is a tremendously valuable thing for learning because in terms of presenting the information, you can only guess what people were thinking when they wrote the code 'cause you don't know who they were.

All you know is you can see the code, that you can see, but you can guess what they might be thinking. But it's up to them in the audience to choose whether they actually want to reveal who they are and what they were actually thinking at that point in time.

Eden: Mm-hmm.

Jon: And that's actually quite an important point I feel in terms of this one aspect of the underlying philosophy of of cyber-dojo.

It's very deliberate that it's anonymous unless you choose to say that you are the avatar in question.

Eden: I think that's really important as engineers are learning a new language, picking up a new framework, really just trying to build skills in their career is you want to... Yeah, people can't be afraid to fail, right?

There needs to be this sort of safe environment that's dynamic that you can learn from each other. And I think, yeah, that's a really key part.

Maybe walk me through the journey. Okay, in my browser, I open up Cyber-Dojo.org, which I think is where your platform lives.

Jon: Yes.

Eden: Could you maybe describe for our audience, like what do you see on that first page? How do you get started? What is the experience of writing a first test, for example?

Jon: Sure. So, essentially, the very first page you see is... There's only really two pages.

The first page is, do you want to select an exercise? There's a whole bunch of pre-canned exercises, the classic starting exercise being Fizz Buzz.

And the second page is, what language and test framework combination are you going to choose? And again, that's a very deliberate part of the design. You can't just choose a language. You have to choose a language and the test framework together.

And once you've done that, you get presented with basically an ID, six-digit ID. And you can choose to share that with everyone else if you want to. And if you do share it, then anyone else can see your work.

There's no login, so it's kind of security by anonymity almost if you like. And when you've done that, you are in a very, very simple IDE effectively, which is brutally simple.

And again, this is a very important key, a conscious part of the design. There's only really one thing you can do and that's hit the Test button.

And when you hit the Test button, what happens is the files that you've been editing in your browser, both the code and the test files sent to cyber-dojo server on the cloud, and it does all the technical lifting to run the source and the tests, well, to run the tests in the particular language test framework combination you've picked.

And then there's a bit of implementation to know the patterns of the particular test framework and therefore it can say, okay, the outcome of that test framework run was green or passed or it was red, there was a failure.

And you simply get back a little traffic light, indicating what the outcome of that test was. And you make some changes, you hit the test again, you get another traffic light.

And you get this sequence of traffic lights that grows in a bar across the top of the page. And you just keep going until you run out of time if it's a timed session or you get bored or whatever you want to do.

And the extra part on top of that, which again is perhaps the core part of the whole thing is that you can click any individual traffic light, and it will show you a diff of what did you do in that particular submission compared the the previous solution between two traffic lights.

And again, the point being that everyone can see everyone else's work, not just in terms of how they finished the work, but in terms of the journey they took to get to where they got to, the mistakes they made, the inspired things they did. Whatever it was, what happens is what happens in the dojo. Exactly as you hinted at earlier of the ability for everyone to learn from everyone else is really what it's all about.

Eden: That's awesome. You mentioned that like cyber-dojo supports a number of different testing frameworks. Which frameworks when you first started building it did IT support and have you added new testing frameworks over time?

And I'm curious, like are you sort of observing which frameworks are most popular, that more tests are being created on and how has it kind of evolved in the last few years?

Jon: So, I think the very first one that was added might have been C and assert as the test framework. Not really a test framework, just assert.

And the reason I say that is because around this time, the reason I was in Oslo where it all kicked off was 'cause I was doing a lot of work for a particular company called Tandberg.

And there's a sort of second parallel story here, which is that I would go... Not just Tandberg, I would go into an organization and say, "Okay, we're doing some training. You've hired me to do this training, let's say, for three days."

And I'd have emailed beforehand to say, "Now when I get there, obviously, we'll be doing C so you need to install the C compiler."

And they'd say, "Yeah, yeah, sure, we understand that we'll do that." And when we get there, you know what, it's not installed.

Eden: Oh no, yeah.

Jon: So you can spend half, literally half of the first day just getting everyone up to speed so that they can run a test.

So that was kind of also in parallel, a backstory about... It was scratching my own itch to avoid that problem and just be more effective and more productive as a self-employed consultant when I'm visiting these various companies.

So this company Tandberg did a huge amount of stuff in C and C++. So that would've been the very first one.

In terms of monitoring and which ones are the most popular, I used to monitor that a lot with Prometheus and Grafana, but I have to be honest, since I joined Kosli and gave up being self-employed, I haven't kept that up to date in terms of looking at it, so I don't know what what the stats are for that.

You won't be very surprised to learn that the most popular languages, for example, were C# and JavaScript.

Eden: Yeah, that still makes sense today. I think there's obviously a lot of trends that continue to evolve with preferences that different engineers have.

But I think, fundamentally, like the classics are still tried and true, and especially for a tool where cyber-dojo is intended to teach engineers new skills, sometimes these fundamental programming languages, it's better to start with kind of like the classics.

Jon: Yeah. It's interesting. Now, you made me think about it. At the time in sort of 2009, 2010, I do remember a distinct conversation I had with a very great friend of mine called Alvi and another guy called Mike Long who was actually the founder of Kosli who I worked for now.

I swore I would never ever work for anyone else, but as the old joke goes, he made me an offer that my wife couldn't refuse.

And at that time, I remember in that meeting we were discussing, 'cause I talked about the idea of cyber-dojo, should we build it or should I build it in Ruby, which was really an up and coming language at that point in time, or Python 'cause they were kind of on an even keel at that point in 2009.

And I chose Ruby and I don't regret that 'cause I love it and it's a tremendously beautiful dynamic language. But in retrospect, Python, I think, has won that race. It's by far the more popular language.

And to answer the other half of your question in terms of other languages that get added and test frameworks, there is a sort of plugin architecture for that.

So anyone can build their own Docker images and just literally plug it in and it'll work as long as they follow the architecture of the plugin. And there are now a lot of support for different test frameworks and Python.

So I would say if I was monitoring, I'd probably find Python was up there as well now.

Eden: That's cool. It sounds like cyber-dojo sort of supports... I think I saw on the list like JavaScript, Objective-C, Ruby, Python, PHP, but there is also the optionality, especially as the industry continues to evolve. I also saw it is open sourced so if someone wanted to build their own server version of this, they could.

Jon: And many people do.

Eden: That's fantastic.

Jon: Yeah, James Grenning is probably the most famous person. He's one of the Agile Manifesto signatories. He does a lot of his training using cyber-dojo.

And he's very generous in his support for the charity that is kind of behind cyber-dojo. It's completely not-for-profit. All the license fees go towards the charity that my friend set up.

And one of the reasons he uses it is exactly one of the origin reasons for me. It's just that he would go to companies, and they haven't set up all the stuff that he'd said they had to set up to do the training he was trying to do.

So his particular area is embedded testing, testing in an embedded area. And so that's what he does in cyber-dojo.

Eden: That's fantastic to see the impact that cyber-dojo has had on teaching these practices to engineering teams.

But I guess I'm sort of curious, like with all the consulting work that you used to do and, of course, this nonprofit that you've helped to set up with your team, do you feel that a lot of enterprises or engineering teams are kind of still starting from scratch and trying to learn the fundamentals and the basics of of how to write or implement test-driven development or agile or any of these practices?

Or do you find that it's more the sort of newer and generation of engineers that need to be trained but the organizations themselves have already adopted good testing practices?

Jon: I would say the level of testing is hugely better than it was when I started in the industry. It's generally only going one way and that's getting better.

I would also say it varies tremendously. The range that you get that I experienced was very great both in terms of the bad being very bad and the good being very good.

But I do think that there is a driver behind why testing... One of the reasons, at least big reason, why testing has become more prevalent and dominant and accepted, and that is DevOps in a funny kind of way.

Because if you were a company that wasn't doing DevOps back in the day and you had some kind of deployment pipeline and you were doing a deployment, let's be generous, once every three months, then obviously all things being equal, what you've got is a system that allows you to deploy once every three months.

And if you suddenly, for whatever reason, decide that you'd like to deploy once every day, it's simply not going to happen. You have not got enough quality built in the system to allow that to happen.

So I would say a big driver, as I kind of mentioned, was that there was a motivation, that's what I'm trying to say. People actually wanted to be able to deploy more and more and more and more frequently. And to do that, you have to have better quality. It's just you do. And so there was a forcing function of pressure, if you like, to be able to add a little bit more functionality and not break the existing functionality that you've got and repeat that and repeat that and repeat that.

And what that ties into, I think, is the ability of tests, a good test suite, if you like, not so much to allow you to specify the behavior before you implement the behavior in the sort of, quote, true TDD fashion, but much, much more in the sense of being able to refactor the what you've already got and add new behavior without breaking the behavior you've got.

So that's kind of the way I see it in my head a little bit.

Eden: That makes sense. Switching gears a little bit to kind of your current role at Kosli. You're the director of software and you're leading a team, you have engineers that you're working very closely with.

I'm curious what you've learned building cyber-dojo or even the best practices more broadly that we just talked about. How or have you been able to sort of create that culture on your team at Kosli?

And is there anything special that you would do that you would recommend other engineering leaders do as well?

Jon: There are some things we do that I'm sort of quite proud of. One of them is that we basically never run tests on our raw machines.

Eden: Okay.

Jon: We always try and run the tests in a manner that is as close as we can get it to two things. And number one is how it'll run on the CI pipeline. And number two is how it'll run on staging prod environment where it actually gets deployed to.

And so that obviously ties into deterministic behavior and repeatability and so we do everything with Docker images.

So if you want to run the tests locally, you just can't. You have to do them by spinning up a container with the code and the tests inside that container, and then you have to shell into the container and run the test inside that container.

So that is, as is always the case, a good and a bad thing. There's pros and cons. It's probably caused us pain at the beginning.

It may be slow to down at the beginning 'cause certainly when you've got only a very small team in a very small code base, it would've been faster to go just raw and not worry about the docker.

It took quite a lot of work to get that going in terms of infrastructure. But I'm totally happy that it's the right decision. And we are expanding really quite rapidly, and we're planning to expand even more this year.

We had a tremendous new developer just join us literally this week. And he was running the tests, I'm not kidding, within five minutes.

Eden: Nice.

Jon: Yeah. So that's one thing we do. And the big downside of that to sort of finish that first thread is that the IDE support is still, I would say, lagging behind. The vast majority of IDEs assume you are running your tests locally.

So we have to be able to switch... We use the IDE for editing the code, but we don't run from the IDE, the tests. We always drop back to the terminal to run the tests.

The other thing we do is we kind of have an unusual pattern of how we write our tests in that-- If you have a kind of a normal canonical test, typically, it might be called something like "test when I do x and the context is y then the outcome is z."

That's your classic. Arrange, act, assert, your three steps. And you just have some description of that in terms of your test function. But if you think about it, that's an awful lot of context to try and to cram into one test name.

So I remember, and you probably have seen this yourself, that, certainly, when I was visiting companies when I worked for myself, there'd often be test names that was literally so long they were scrolling off the right hand side of the screen.

Eden: Yeah.

Jon: So the more I thought about that, the more I thought, well, actually you are trying to do something there that it's just not designed to do. A normal non-test function is not designed to carry all that context.

There's only kind of one context-free method function in a a classical server, if you like, or program. And that's Main if you take the C analogy. It's just called Main and there's this convention that Main is where the program starts.

So we don't do that. We have a generator that generates a random eight-digit ID and our tests are called test underscore and this eight-digit ID. But what we do instead is we put really as good as we can make it doc strings inside the Python tests.

And the doc strings are edited over multiple lines to try and express as richly as we can this idea of all this information that perhaps you were previously trying to capture in the name of the test or perhaps in a Gherkin style arrangement if you were doing something like BDD, something like that.

So we do that, and there's a couple of interesting reasons why we do that. One is that having each a non-changing individual ID for each test turns out to be tremendously useful for repeatability, for deterministic behavior because you can hang off all the points of variability where something would otherwise be non-deterministic.

And for that test, you can guarantee at the scene in question, you'll always get the same behavior and the same inputs give you the same outputs and vice versa.

And you can, as I say, generate pretty close to 100% deterministic behavior, and therefore you can do things like caching.

'Cause it's certainly the case that when you run most of your tests or when you run all your tests, most of them are not changed from the last time you ran them.

Eden: Yeah.

Jon: So what we can do is with... Not very much engineering, We can run each test. And if it doesn't work from the cache, we can automatically run it without the cache.

And 9 times out of 10, the cache works. And the speed that you get in running those unit tests is really tremendous.

Eden: How much of this infrastructure was already in place before you got to Kosli? Or did you kind of set all of this up yourself? Are you still writing code actively today as well or are you mostly managing?

Jon: So none of it was there. When I started, I was employee number three and there was only James and Mike. And they would literally sort of bootstrap the company from the ground up.

I mean, Mike literally would write code the day before a demo to try and really get things going. And there was a lot of things that had to happen in the early days that I could do a whole new podcast on some of the stories there and some of the horrors that had to be overcome.

But yeah, there was nothing there and we had to build it all ourselves. But that's not to say I did it. I just happened to be the first person there.

But within only two or three months, there was at least another two people who joined. So it's been a collective effort.

To answer the second part of your question, my role in terms of hands-on coding is gradually dropping away because I've got all these other tremendous engineers who frankly are just much better at me because I am getting old, there's no question about it.

I'm getting older. I can't pound out the code in the tests five, six, seven hours a day, like I could five days a week. It's just not there in me anymore.

Eden: How do you make sure in your either recruiting process or onboarding and training process that you're able to preserve the culture and sort of your vision for the team across all these new hires, especially with the chaos of a startup?

Jon: I would say the main thought on my head, to answer that question. is that I kind of see, to stereotype slightly, two kinds of developers.

There's developers who I would kind of put myself in this bucket who, on balance, prefer to really get something working with lots of tests for the edge cases, think about things a lot, and get stuff that's out there that just works first time.

So that's kind of what I did for cyber-dojo. I mean, cyber-dojo's basically had only one bug over 10 years. And there's another kind of developer who are much more focused on just certainly doing less rigor, shall we say, but more agile, I think it's fair to say.

It gets something in front of the customer quicker. It's a bit rougher, but that's okay. In many, many, many situations, that is perfectly, perfectly okay.

And for Kosli, I would certainly say that the latter has to take the precedence because we are a startup, we are genuinely doing something that is breaking new ground.

And if we spend ages and ages and ages trying to predict what the customer wanted and polishing that before we put it out, we would just be wasting a lot of time 'cause it will never get it right.

We'll always be guessing wrong. We need to get it in front of customers and get the feedback. So that's the tension. And I think it's a healthy tension because if you let the code go too much without having some kind of testing infrastructure behind it, let's say, then that stores up problems very quickly.

But equally, if you don't get it out in front of the customer quickly enough, that stores up a different kind of problem. So that's a tension that definitely exists in the team, but it's a healthy tension.

And sometimes you have to pick your battles and stick up for what you think. So if I think that we are perhaps not quite doing enough testing or the coverage is dropping, let's say, then I might raise that.

But overall, I'm totally, totally happy with the code base. We do measure things like coverage as kind of meta tests. We know when they drop below a certain threshold, we have to choose whether we consciously drop the threshold or add more tests or whatever we do.

Our problems are not that we don't have enough coverage on the code base. Our problems are that we need to get more features in front of the customers more quickly, get the feedback going and learn what the customers actually want.

So that's the tension, that's the balance. And in terms of culture, it's trying to maintain that balance in a healthy way 'cause sometimes you get this, there's this illusion that the best teams are all lovey-dovey and totally each other's friends, and they all go out to the pub every Friday night or whatever it might be.

But I don't quite see it like that. I think in a good team, a healthy team, they often is tension because people are fighting for what they believe in, but in a positive sense 'cause they really, really want the companies to succeed. And that's how I feel we are now at Kosli.

Eden: Yeah, I think that makes a lot of sense. And it sounds like you guys have struck a really good balance between making sure that the foundation is there, the engineers are writing tests, you have thresholds, you have metrics that you're tracking.

'Cause I have heard a lot of stories of startups that sort of fall into a trap of, like, "well, I don't even know if this feature is going to be accepted by the customer. Let me just build the version of it without any testing. I'll go back and I'll deal with it later."

And you never do, which is inevitable... I think that's a challenge beyond engineering. It's always just like it's easier to invest in it at the time that you're building it. When you have the context. you don't have to remember, wait, what did I do here? Why did I architect this in this way?

Jon: Right.

Eden: Doing it at that time. But just the balance of not overdoing it, I think, is somewhat of an art.

Jon: Doing just enough. Yes.

Eden: Just enough.

Jon: It's totally about, really, it is for me almost all about this idea of refactoring 'cause as the code base gets bigger and as I get older, there's just less and less of it I can hold in my head.

There's just no possible way I can remember all the decisions that we made about why certain things are the way they are. And so those tests act as a sort of collective memory of this is happening this way, and it is deliberate, and this is the answer you should get in this point.

And it remembers that information for you. And you are doing something else weeks and months, years later. And suddenly this little test fires often is failing 'cause you've broken something and it's remembered for you.

It is tremendous. The confidence it gives you, when you've really got a code base that has that support, it's so brilliant that you feel sorry for developers who've never experienced it 'cause it's so different when you've got it.

Eden: Yeah. It is like a log or a chronology, a diary, if you will, that sort of keeps track of the progress of a team or an individual engineer's contributions.

It's that internal institutional memory for the team. It helps to more clearly define like product features 'cause I think oftentimes that definition of coverage, like what's even in the denominator of coverage.

Sometimes people forget if you don't document it. But the inherent process of building and writing tests is its own documentation.

Jon: Yes. I mean, as always, you can... Sometimes you can write tests that are harder to understand and they need a bit of refactoring, but that's just normal.

Eden: Yeah.

Jon: Which is also another interesting sort of philosophy I have now that you've made me think about it.

I quite strongly have the view that the code and the tests are equal first class citizens in a co-evolving system. To be honest, that's different to many, many places I visit or used to visit where the code is definitely dominant and the tests are a second class citizen that in many ways are an afterthought.

And that is quite a deep philosophical thing for me, a pattern for me because I do see it as being very tightly wound up with this idea of being able to do what you need to do in a certain amount of time.

And there's an analogy I have in my head for that, which is in living systems, I'm very interested in systems thinking. And there's a very famous systems thinker called Gregory Bateson. And he said in the 1970s, "If you want to understand how to build robust systems, you should look to nature."

And what he meant by that was that life on earth has been on earth for 3.8 billion years or whatever it is. And that means that you and me and everyone who's here and everything that's alive is the result of an unbroken sequence of survivors that goes back 3.8 billion years, right?

Eden: Mm-hmm.

Jon: Now, if you think about it, that is utterly mind-boggling. How can it be that robust? And so that was his advice, and he turns out he's right. And many people have since studied that.

And to give you one quick example, if you take the blood sugar level in a mammal, if you eat a donut, let's say, and your blood sugar spikes, then that's not good.

Unless you can get that blood sugar back into regulation within a really quite small amount of time, chances are, you're going to die, right? But of course, that doesn't happen.

And the reason it doesn't happen is because there's a process in the body that actively takes the sugar out of the bloodstream. But if you have that process working on its own, what would happen is that you'd still die because all the blood sugar would get taken out of the blood.

So there's a different, there's a second system in the body and its job is to counteract the first one. The first one takes the sugar out and the second one puts it back in when it's too low.

Eden: Yeah.

Jon: And what you get is this beautiful paradox, if you like, that there's these two systems in the body. Just to pick one example. There's hundreds of times this happens.

But in the glucose cycle, there's these two systems that are fighting against each other all this time, constantly fighting against each other, right?

And there's this tremendous activity. And what is the purpose of this activity? The answer is to keep something else sane, something else constant. And that I find a beautiful paradox.

I use that as a lesson for many things. For example, if something is constant in this crazy world that we live in, there's probably a good reason why it's constant.

In other words, it's a good hunch to look for other processes that are keeping it constant. That thing that's being kept constant is something that culturally this company values for whatever reason.

And with that, probably means behind the scenes, there are systems in process and things in place that are keeping it in place. And vice versa. If there's all tremendous activity for whatever it might be, there's probably a reason for this activity.

Its purpose is to actually regulate something else within a certain timeframe. If you're doing it really consciously, it comes back to this idea of deployment frequency a little bit.

The system has to be able to regulate within a certain amount of time. That's kind of what regulation's all about.

Eden: I really like that analogy. There's probably more that we can be learning from biological systems, other systems that we can apply to engineering, for sure.

Jon: Yes. I'm sure there's echoes of it in chaos engineering, for example.

Eden: Yeah. Honestly, we could do a whole other podcast episode about that and maybe we should.

Jon: Yeah.

Eden: But maybe to kind of wrap up, I realized there were two things, two questions maybe last for you is we never just sort of told the audience about Kosli.

I don't know if you want to spend a couple minutes on that. And then, yeah, any other sort of final parting thoughts that you'd like to share with everyone?

Jon: So Kosli was a company that was born in the COVID times. It's always been remote only. And the story about that one is that Mike Long, who's the founder, would do consulting for companies that were in a regulated space, such as banks, for example.

And he would constantly find the same problem, which in a nutshell was companies that had crossed over the bridge and perhaps were doing DevOps.

And so all the inefficiencies and bottlenecks and batching that was happening previously between dev separated from ops, they were getting a handle on that.

But frankly, it didn't make a blind bit of difference because all that was happening was they'd moved the bottleneck and it was now at the compliance. They still couldn't actually deploy things as frequently as they'd like.

So he saw that problem over and over and over again, which for me is just a completely natural evolution of where is the bottleneck now, this continuing story of agile stroke DevOps, if you like.

And he had some insights about how to solve that problem in a nice way, a clean way with a really sharp tool that would do what you needed to do 'cause it's a really tricky problem.

And so in a nutshell, Kosli was born to try and solve the problem of compliance in regulated industries in a modern way that allows you to go faster, which actually allows you to be safer.

That might be counterintuitive, but a nice analogy here is if you're ice skating, for example, it's actually really bad idea to be very slow when you're ice skating 'cause you just can't keep stability.

So going faster would actually make, for example, banks in many, many cases less risky. They would actually be more in control of their risk. So what Kosli's trying to do is modernize the whole idea of compliance.

And frankly, it is amazing no one's attempted to crack that area before because it's so ripe for modernization, let's say.

Eden: Yeah. I think you guys are building it in a very incredible platform. I can see how your background and what you developed with cyber-dojo and sort of the way that you think about software engineering and product development, it suits itself to this role and makes you like a perfect fit for leading the team on that front. So that's amazing.

Jon: It's certainly true that in my mind, compliance is just another form of testing. I mean, in a nutshell, compliance is really very simple.

It's simply the idea that you have to write down what you're doing, you have to do what you said you're doing, and you have to prove that you're doing what you said you're doing, right?

That is it. But what do you mean by the proof and how do you get that proof? Is it a continuous thing or try and do it every once every three months or six months, whatever it might be?

You want to be nearer to the continuous end of things because, again, that's the way to keep control.

Eden: Yeah. Thank you so much, Jon, for joining us on the How It's Tested podcast. I've really enjoyed this conversation. I think we're always looking for different perspectives and voices on how to approach building and scaling engineering and quality and product teams.

And I think what you've built with cyber-dojo really just like makes it a lot easier for people to not be so intimidated by TDD.

And I hope this podcast helps to spread the word about the platform. And also, what is the link again? It's cyber-dojo.org, right?

Jon: That's it, yep.

Eden: Cool. I hope everyone listening will take the chance to check it out. And thanks again, Jon.

Jon: That'd be great. Thank you.