Bert Hubert

That's probably where you read it. The thing I put it in there, I got it from an Australian guy. And he said, if you have dependencies in your software, schedule some time. maybe every quarter, just to take a look at all your dependencies. How are they doing? Are they still being maintained? Are the security releases coming out? Has the new VC started the monetization cycle yet?

That's probably where you read it. The thing I put it in there, I got it from an Australian guy. And he said, if you have dependencies in your software, schedule some time. maybe every quarter, just to take a look at all your dependencies. How are they doing? Are they still being maintained? Are the security releases coming out? Has the new VC started the monetization cycle yet?

And the idea there was that if you do this on your time schedule, you find out ahead of time that things are not going well. And the other way is that you figure it out because the stuff doesn't compile anymore.

And the idea there was that if you do this on your time schedule, you find out ahead of time that things are not going well. And the other way is that you figure it out because the stuff doesn't compile anymore.

But interestingly, it's a very interesting, good concept. I sometimes get that reaction when I tell people about unit tests and regression tests. They say, well, look, the software worked the last time I used it, so it's still going to be working.

But interestingly, it's a very interesting, good concept. I sometimes get that reaction when I tell people about unit tests and regression tests. They say, well, look, the software worked the last time I used it, so it's still going to be working.

And I'm like, well, just write some unit tests and see what happens, which is basically the sort of same thing where you just ask the computer to add two and two and you check – If it's still four. But still, so often unit tests will find that you broke stuff, even though you thought it impossible that something got broken.

And I'm like, well, just write some unit tests and see what happens, which is basically the sort of same thing where you just ask the computer to add two and two and you check – If it's still four. But still, so often unit tests will find that you broke stuff, even though you thought it impossible that something got broken.

So I do enjoy that mindset where I say, look, we're still going to test it every time and do that. Because you never know what happens behind your back. But there are people that are like, oh, I'm not going to write unit tests because my software worked the last time.

So I do enjoy that mindset where I say, look, we're still going to test it every time and do that. Because you never know what happens behind your back. But there are people that are like, oh, I'm not going to write unit tests because my software worked the last time.

And it's magical. PowerDNS was, of course, very old. And in 2001, we made the first regression tests and unit tests. And that was like an amazing feeling that your tests discovered that you made a mistake and they told you before you shipped. I mean, it's still a good feeling. And I sometimes give training to scientists on programming.

And it's magical. PowerDNS was, of course, very old. And in 2001, we made the first regression tests and unit tests. And that was like an amazing feeling that your tests discovered that you made a mistake and they told you before you shipped. I mean, it's still a good feeling. And I sometimes give training to scientists on programming.

And when I show them the power of unit tests, they go like, wow, that's just awesome that you get an email message that you made a mistake instead of getting a complaint later on.

And when I show them the power of unit tests, they go like, wow, that's just awesome that you get an email message that you made a mistake instead of getting a complaint later on.

Yeah, that's the same kind of concept, yeah.

Yeah, that's the same kind of concept, yeah.

I struggle with this myself because I do a lot of reinventing the wheel often because I know that I could spend the time learning about your dependency and then I would still be disappointed because like two years from now, the dependency will be different again. So I do often spend more time than is wise probably re-implementing some simple things.

I struggle with this myself because I do a lot of reinventing the wheel often because I know that I could spend the time learning about your dependency and then I would still be disappointed because like two years from now, the dependency will be different again. So I do often spend more time than is wise probably re-implementing some simple things.

I draw a very hard line at cryptography, for example. I mean, unless you are like a famous cryptographer, you should not be doing cryptography. You should leave that to someone else. But even then, if you look at the state of many cryptographic libraries, OpenSSL has been a sort of disaster zone for years now. But I draw a very strong line there. You do not build your own cryptography.

I draw a very hard line at cryptography, for example. I mean, unless you are like a famous cryptographer, you should not be doing cryptography. You should leave that to someone else. But even then, if you look at the state of many cryptographic libraries, OpenSSL has been a sort of disaster zone for years now. But I draw a very strong line there. You do not build your own cryptography.