An interview with DHH about his views on software testing, TDD, and exploratory testing.
Transcript for episode 45 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
Welcome to Test and Code, a podcast about software development and software testing.
David Dynamyer. Hansen is the creator of Ruby on Rails, founder and CTO of Basecamp, a best selling author, a public speaker, and even a Leman’s class winning race car driver. All of that, of course, is awesome, but that’s not why I asked him on the show. In 2014, during a realscomp keynote, he started a discussion about damage caused by test driven development. This was followed by a few blog posts and then a series of recorded Hangouts with Martin Fowler and Kent Beck. This is what I wanted to talk to David about, this unconventional yet practical and intuitive view on how testing and development work together. It’s a great discussion. I hope you like it.
This episode is sponsored by JetBrains and PyCharm. My team has switched to PyCharm for Python development, especially test development, because it works with our workflow and saves us a lot of time.
The virtual environment and Get integration has helped the team utilize these great tools without any hiccups. The incredible code completion helps maintain workflow speed by not having to jump to another file to look up things like parameter order. The optional Vim emulation allows those of us with many years of them muscle memory to keep those efficiencies while still being able to use the Midi speed boosting features of PyCharm. But the pipe test support is really what sold us. And now with the 2018.2 version just released in July, pytest got even more fun. Code completion now works with pytest fixtures and even Parameterization, and you can even rerun an individual parameterization test case.
I don’t know which feature of Pie Charm are going to be the features that save your team time, but if you value your time, you owe it to yourself to try Pi PyCharm.
Use the special link Testingcode.com PyCharm to try PyCharm Professional for free for three months. This is just for test and code listeners and it’s only good until September, so don’t forget now on with the show.
Thank you for agreeing to come on Test And Code.
Sure, my pleasure.
I started writing about testing and software testing in 2012 because I didn’t agree with what a lot of the writing was out currently available and so I started writing about it and then people of course started asking me about test driven development and I was leery to really share my opinions because my opinions were so much different than what people were talking about at the time. And then some research in 2014 ran across the Is TDD Dead series of interviews that you did and then backtracked and watched your Rails conference keynote and actually kind of impressed with your swing towards conventional wisdom or swing at it and wanted to have you on. There might be some non Ruby or non web developers that listen that don’t know who you are. I know that’s a hard question, but who are you, David?
Sure.
So I’m the creator of Ruby on Rails, which is probably the most relevant part to this discussion here, and also one of the founders at Base Camp, a software service company that sells project and progress management software, and has been doing so since 2004, which was also the year that Ruby on Rails was initially released. Ruby on Rails is a web framework built on top of the programming language Ruby that I picked up in the early 2000s and have been working to improve and better ever since. And as a sort of outlet for my dive into software writing and during the process of creating those two things, I’ve also sort of just come to realize that I have certain opinions about how to develop software derived from how I have developed software, and I’ve been sharing those for a long time. And as you say, one of those flights has been the question of testing, which in the Ruby community was something we embraced very thoroughly and very early. The same with Rubian Rails. One of the perhaps surprising things of Ruby and Rails in the beginning was that we generated test ups. When you set up a empty shell of an application, Rails has this generator that sets you up with a skeleton for a new application, and as you use that generator, you simply by default cannot avoid having test stops already produced for you because we expect that you’re going to test your whole application.
So from those early days, there was kind of a close Alliance, I’d say, with Ruby and testing, and to some extent TDD. There were a lot of proponents in the Ruby community of TDD development, and I sort of counted myself philosophically aligned with that for a while, if not practically aligned. And I think that that tension between having a superficial philosophical alignment with TDD and then the lack of a practical adherence to its process finally just burst over. An issue came to the forefront with my 2014 RailsConf keynote, where I questioned just what is this document that we are adhering to here? Is it actually serving our purposes? Are we writing better software when we think we have to write every single test first? And that then sparked the conversation series we talked about is TDD debt with Kent Beck and Martin Fowler, and I think hopefully brought a bit more nuance to that discussion that not doing TDD all the time was not a moral failure on the path of any developer, and that you could develop great software. And in some cases, as I argue, even better software if you don’t write your tests first, and more specifically, if you don’t let your tests drive your design.
Yeah, I really resonated with that as well, because my introduction to test driven development was when it was called Test First Programming, and it was sort of part of Extreme Programming. And the point there was about the tests as far as I can tell it wasn’t about the design. And then when I came back to it, hearing all these people saying TDD actually isn’t about testing, it’s about design.
I really was confused. I didn’t understand.
What I really want to do is have developed tests that verify that my software works.
Yeah, I think it was sort of both. But the angle that got pushed at some point was certainly that this is about design. I think when Kent Back launched Extreme Programming, he did mention the benefits to the design from running your test first. But I’ve had many conversations with Kent both in public and in private ever since. And I don’t find this very stringent reading of his philosophy to be that like, this is only about the design. It got so far along that some proponents of TDD and its strictest sense would say it’s not at all about the test. Like the tests are sort of almost inconsequential, and that the primary purpose, if not the sole purpose, of TDD, is to design better software. And that was the part I really started taking true offense to when I saw some of the software that came out of TDD practices. And I thought, wait a minute, this is not better. You can write the same piece of software in a better, more readable, clearer way if you’re not constrained by this test driven approach, that the tests have to have the number one priority in your list of priorities for how you write your code. And there was just a lot of techniques around dependency injections and how you got your marks and your stubs to work. Well, how much isolation you had to do this kind of tied into the discussion about what is a unit test, which was also a long kind of philosophical, I think, detour for the community to sort of your tests not only have to be written first, they have to be written in total isolation. And that isolation means separating the thing you’re testing from every single dependency could possibly have, down to the point that you truly are testing in isolation. That that’s what unit means. That never squared with my definition of a useful unit test.
Sometimes that’s the case, but oftentimes it’s not. And I think some of the heresies in the rail setup that we had long debates about was, for example, that we called the model tests. We have unit tests, even though they touched the database, they touched your layer, they touched a bunch of things. So in some people’s minds, those things counted almost as integration tests. And I was like, you know what? I’m not terribly interested in that discussion because I don’t think it’s helpful. Let’s just call it model tests. So that’s what we kind of sidestep that whole discussion in the rail set up by going with a broader, less contentious term. But I think it illustrated the fact that there’s just some weird adherence to some philosophical lines on testing that just didn’t help me. Right. And when I spoke to Kent, for example, many times, he’s a very practical person. And the meetings of the minds we had were always around the practical aspects of are these tests allowing programmers to have confidence in the code that they’re publishing and releasing? And that should be the focus. I think we kind of somewhere along the line, put the golden calf up and started worshipping these externalities of coverage or isolation or the design driven aspects of it without taking a step back and realizing or evaluating. Are we writing better software? Are we writing software with higher confidence? Are we writing software that reads better? And I think that was kind of the angle I was trying to push in 14 with that keynote and just kind of let’s hit reset here. Let’s take a step back and consider testing as just one of the components that we’re using to get to this utopia of beautifully well written software.
Yeah.
So that was in 2014. It’s 2018.
Has your mindset or philosophy changed or altered since then?
No, that’s the short answer. I’d say slightly longer answer is that this discussion, thankfully, has somewhat receded into the background a bit, and I see less sort of pseudo religious arguments around TDD, and that those arguments, when they do happen, carry less weight and involve and interest fewer people. So I think we got a healthier relationship with testing in the Web community and certainly in the Ruby community, perhaps in part through that reset, and perhaps in part through other people’s realization of the same thing.
I spent less time worrying about the specific terminology around, let’s say, model testing versus unit testing. And I certainly don’t want to spend any time I certainly don’t spend any time actually feeling bad about not doing TDD, which really I write a fair amount of software, and TDD is occasionally a thing I will pull out. And really, it’s not so much TDD. It is test first. But sometimes in isolated cases, I do find value in writing the test first and then filling it in with my code afterwards. And that’s usually in the case where I’m exceedingly clear on what I want and that the code that I’m writing has sort of a goes in, B comes out transformational code. In that sense there I find a test first to be occasionally a helpful practice. But as an overall technique of developing Web software, no, I don’t write my test first. I always fill in my tests afterwards.
You say you’re still writing a significant amount of or at least you do spend some time still writing software.
Oh, absolutely.
I write a fair amount of software. I contribute to Ruby on Rails, the framework still in large degrees, and I continue to write software for the current version of Base Camp that we have in future projects. It’s sort of waxes and wanes. I’ve been writing a book this spring, and that’s taking a bunch of time. So I haven’t written as much software in that duration. But yes, software is absolutely still key to what I enjoy doing every day, and I try to do it as much as possible.
I want to get to maybe a division of labor of QA versus developers and see if you have any thoughts on that. But one of the things while we were talking about your keynote, I relistened to it the other day, and I guess I had forgotten that it may have been that keynote that gave me the idea of thinking of writing software, like writing Pros or writing a book or writing an article or something, and thinking about that in terms of the software you write as a first draft. So the tests that you write around it should allow for second, third and fourth drafts to be written, even if that’s like moving chapters around or moving classes or functions.
And to me, that sort of mindset helps me not think about Dakota right as being so precious and also allowing me to just wholesale, I want to write tests that I can trust enough to where I can just throw away a big chunk of the software and rewrite it if I feel like I could do a better job the second time.
Did you get that idea from somebody else?
I’m not sure. I don’t think that seeing software as discipline of writing is an original idea on my part, that’s for sure. But it’s certainly one that I’ve embraced and the one that resonates most clearly with how I think about writing software. And I think that that’s important. I think it’s important that you have a paradigm to think about software, and for a long time, people thought about software as though it was, say, construction. And that leads to a myriad of subsequent conclusions about how you should approach the process of writing software. If you think about Software’s construction, you are in a very different frame of mind than if you think of software as another paradigm that’s been used like gardening, or if you think about software as I prefer to do as writing. And I think, as you say, there’s just a bunch of metaphors that lend themselves to illuminate the process that you’re going through when you pick either of those paradigms. And for me, writing is intimately tied to this idea of the draft, and that I, as you say, will decide sometimes to rearrange things dramatically in the process of writing. And I think perhaps the utopian version of that with regards to testing is that, well, you can just have your test and then your test will allow you the freedom to do all that draft rewriting afterwards and with full confidence. I haven’t actually seen that pan out too often, which is one of the reasons that when I am in the most vague stage of the draft, the earliest stages of the draft, where I’m not even sure what the classes are supposed to be called, where I’m not even sure where the responsibilities between classes are supposed to lie. I don’t really write the tests because I know that I’m sort of shuffling things around enough that it’s more of a hindrance to have those tests, and they’re more likely to hold me back from doing the drastic changes that I want to make to my draft than to actually help me. Because at that stage, I’m not in the stage of sort of making it right. I’m in the stage of even either figuring it out or even basically just making it work. And in that early stage of the draft process, I need to just be able to crumble up the whole paper and throw it in the waistband and then take a brand new sheet of paper and do something that’s perhaps dramatically drift different than what I had otherwise intended. And then once there is an outline where you go like, okay, here’s the structure. That’s reasonable. Yeah, I might change a few paragraphs or a few sentences or insert an extra word, but the rough outline draft is there. That’s when I start going, okay, maybe test would help. And usually I don’t even get to that point. In a theoretical sense. I get there in a very practical sense that let’s say I’m working on a piece of Web software. I’ve been now reloading my browser three times where I’m trying to change something to make the code actually work. Right. And then I get annoyed. Then I start seeing like, okay, actually just refreshing my browser to see whether the changes I made were the ones I wanted is inefficient. Now is the time for testing, because testing is just a more efficient way of verifying these things. It’s an actually an easier way when you’re making subtle changes to the program, and then it becomes a really practical matter. The tests are here to help me. They will help me finish this piece of software faster than if I didn’t use tests.
And that, to me, is the primary value.
Yeah, I like that fulcrum point of at the point where writing tests will save you development time.
That’s a good place to start.
It’s nice.
So how big is Base Camp now in people?
So Base Camp, we’re 54, 53 people at Base Camp, I believe, about.
Let’s see, I should know these numbers by heart, but I don’t like twelve developers, maybe 14. I should have a clear account, but it’s thereabouts.
So it’s not a large company, neither an overall headcount, and certainly not in terms of technical programming crew either. And those twelve to 14 people, or whatever it is that we have, are subdivided into even smaller groups where the largest team is for developers.
So we write software with very small teams, and that has been one of the factors driving a lot of opinions that I have about software that I come added from, hey, if you have two developers, one developer, three developers, how do you look at making them efficient and effective and give them the leverage, since they can deliver the kind of software that we want to deliver without growing the size of the company to the hundreds of people, as many other companies have done? And we all make different choices. And the trade offs that we’ve focused on and the technical work that I focus on is to enable a very small company like that in the grand scheme of things, consider the number of customers that we have and so forth to be as effective as we are. Like Ruby on Rails itself came out of that idea that as a single developer, technical person, operations person, as I was at the time, what kind of tools would I need to be able to create software in the form that we wanted to? And could I create that software with the existing tools as I sought them? And the answer for me was no. So that’s what led to the creation of Ruby on Rails, and it continues to drive the decisions of Ruby and Rails, and it continues to also drive my opinions around testing. And you mentioned QA. So one of the evolutions that we’ve had at Base Camp over the years is the addition of Exploratory QA that’s based on non programmers. We have a QA Department of two people at Base Camp that are full time focused on Exploratory QA, which was one of those disciplines that it seemed we sort of lost into shuffle as XP and Agile principles took over and the responsibilities of the individual programmer became greater, that not only were they supposed to be programmers, they were supposed to be analysts, they were supposed to be QA people, they were supposed to encompass far more than what had been the norm previously. And I think there was a lot of good that came from that. It was very empowering to think that a single programmer could do all those things. And in many cases, it rectified some real schisms and divisions in the sort of structure of software development that had existed before, like throw it over the wall QA and so forth, that there were some real problems with the structure of the past. But I think the pendulum swung too far, and especially as it goes with regards to QA, it’s swung so far that I’ve seen lots of shops that are at our size or little smaller, a little bigger still, having absolutely no concept or perhaps to some extent even respect for the idea of manual QA Explorer QA, because there was a bit of an indoctrination that basically said, hey, if you just have programmers who write tests as they write code, you will have faultless software, and you don’t need this type of separate QA. And clearly, that was a fallacy and I think sometimes you need a certain amount of I don’t really like this word, but scale or reach to realize that, like, if you have a piece of software that is used by ten people, you can tend to overestimate the quality of that piece of software because ten people will not hit that many edge cases. If you have a piece of software that’s used by hundreds of thousands of people or even millions of people, well, you’re going to hit all the edge cases and it’s going to reveal to you it’s going to turn on the light in the entire room at a very high brightness, and it’s going to reveal all the corners that had sort of stuff in them that you should have cleaned up. Right. So that was kind of a little bit of the process that we went through in the early days of Base Camp. We didn’t have anyone doing Explorer to AQA. All the bug hunting was basically done by programmers, designers, or customers. And at a certain scale that’s just inefficient. And it kind of comes back to that practical point where I start writing my tests when I feel that writing test is easier than doing the other way. Right. We arrived at Basecam at the point where it was simply easier to have explored to a QA, have an in house before release than it was to release a piece of software to hundreds of thousands of people and then listen to tens or hundreds of bug reports coming back from those customers complaining about the issues that were there. Right. So it’s one of those areas, though, where I feel like as an industry, certainly in the web sphere, we used to have far more of a focus on this exploratory QA. And there used to be books and there used to be sort of professionals. Not that there aren’t still. It’s just that they don’t have the prominence that I feel like they probably should have. And that probably delayed the embrace at Base Camp of Exploratory testing by several years because this was just not seen as the norm. This wasn’t seen as a natural evolution for a software crew that they should add Explorer to a testing, which I’ve read a bunch of software development books from the 90s and Steve McConnell’s Code Complete. I remember I had this anecdote about Microsoft, how they used to have, I think, three testers per developer, and you read an anecdote like that, and then you try to square that with the sort of information. And I was going to say propaganda, which is hard, because I don’t really mean that. But that is the word that comes to mind, the propaganda from the Agile camp saying, like, you don’t need any of these things. And you could just go like, really, there’s something missing in the middle between those two extremes, definitely. And one way of looking at that is sort of that triad of theses antiseces and synthesis that you had the original thesis of like, oh, well, we need three to one. Let’s just take that right. Three to one tester to a developer. And then you had the antithesis of the agile development movement saying, what are you talking about? You don’t need any of these things. Just make your developers write tests first and you will not need QA at all. I mean, I’m completely overstating and caricatureizing these things, but then you finally get to thesis where you go, okay, actually, maybe there is some value to it. Maybe three to one ratio is not a healthy ratio in most cases, but there’s some ratio that probably is healthy. And at Base camp we’ve ended up with a ratio that’s closer to, let’s see, one to four, maybe.
So four developers, one QA person. I don’t know if that’s the right ratio. It seemed to work okay for us, but just the idea that there’s some place that there’s some ratio where it’s helpful, I think it could be a sane outcome of sort of this, these antithesis and synthesis.
You’re also building a product that you use yourself as a team, right?
Yes. And I think that fact learners for a while or perhaps allowed us to neglect this Exploratory testing because we kind of felt like, well, we know whether it works or not, we’re using it every day. And that was true to some extent, at least in the beginning, that we were the most active users of Base Cam. So we were very likely to simply find the faults and errors in our software as we were using it. And that was true.
It just had its limitations and it had a tipping point where at some point we had a combined customer base that did find more problems than we were able to find just on our own, just by using the software.
It does make a big difference, that ratio of Exploratory QA to developer changes if the developers aren’t using the product at all.
I agree.
It’s also, of course, related to the complexity of the software and how much legacy you have and integrations and so on. That Microsoft anecdote was based in part on the fact that I think that was probably from the Windows 95 team and that they had to ensure backwards compatibility to some Dos version that went back I don’t know how long based on all sorts of hacks and compromises. And Microsoft having an ironclad policy that all existing software must continue to work. So obviously they just have different concerns. It wasn’t because they were doing it wrong, it was because different models.
Exactly.
All of your automated suite is still done by the same development team that develops the software.
Correct. So the Exploratory team, we have, the two people we have, they do manual testing, they click around the app and input all sorts of education data and use it with different devices and all the sort of black box testing that it can be done and it can be helpful. It’s funny that the way I see it or the way I got exposed to that a lot was when I was interested in game development, that in game development it was very common to actually have large game tester groups that would do this kind of black box testing.
Right.
They would simply just sit down and play the game and try all sorts of things that the developers wouldn’t have thought of. Right. And it’s basically just the same principle that you have people who just sit down and do all the things that the developer would not think that users should or would do.
Yeah. I remember hearing about those types of jobs while I was in College and thinking, why didn’t anybody ever mention that when I was in high school that that was an option?
Yeah. I think unfortunately the idea of sitting and playing a game all day long sounds more appealing than it actually is when you have to sit and play a beta version of some game and try to beat the same level for the 500th time. Maybe this glamorous as it might appear, but still, as far as jobs goes, not so bad. Yeah.
So we talked about the structure of the development and a couple of QA people for those twelve to 14 developers. At the top of Base Camp is you and Jason, is that correct?
Yeah. We’re the two founders that are still involved with it, and we’re the only two C level executives. I’m the CTO and Jason is the CEO.
Okay. Yeah, that was my question. How is the division between you and Jason, CTO CEO? I don’t really know what that means.
But yeah, that is actually a little fuzzy. I think a clear way to describe it in terms of the product development is that Jason is head of design and I’m head of programming, and that’s the division of labor, not even as heads, but more as in actually doing. When we start working on new versions of Base Cam or any new product for that matter, Jason gets dirty with the design and I start to do a bunch of the programming. And that was how Base Cam itself was born, too, that Jason did the bulk of design, often with assistance in various forms, and I did the bulk of programming in the beginning without assistance and then subsequently with assistance once the company grew up in.
One of the questions I forgot to ask you about, I was wondering if the lean movement or lean software development or any of that affected how you think about things or if that was tangent.
I think both lean and agile obviously are interrelated in various senses, and we took inspiration from both ideas or from both sort of cultures at Base Camp, but we never really followed any capital letter methodology.
We were never say Cavalc Scrum or Lean or whatever. We just took inspiration from these lines of thought and incorporated it into something that would work for us at the different stages of the company. So today base camp is 50 some people. But for a long time we were seven, and for a long time we were twelve, and then we were 20. And we didn’t have this rapid growth that some companies go through. We stayed at those levels for quite a while, and there were a certain style and way of working that worked very well at those levels. So, for example, when we were seven people, we didn’t have any export to QA. Right. And that would probably not have been the right move either to hire someone at that level to do that, because they were simply more important things to do and the criticality of what we were doing lower and we had fewer customers and blah, blah, blah. But then once we reached a certain scale, a certain level of certain reach, then it did make sense. And then the practicality of having someone do, for example, Explorer to a QA slotted. Right in. But I think having sort of the flexibility to constantly revisit your methodology and your approach is key to getting the approach that size appropriate.
That I’m fond of saying in technology terms, that there’s a lot of software development patterns, for example, that are exactly what, let’s say Amazon or Facebook needs and are exactly the opposite of what a company like, say Basecamp needs. One of the ones I love to harp about is micro services. Right. Microservices have sort of exploded in popularity over the last several years. And one of the reasons it did was because people saw that, say, an Amazon or Netflix or whatever, that they had embraced that pattern. And then they went like, oh, well, hey, if it works for Amazon, if it works for Netflix, surely it should also work for our company of ten developers. Not realizing when there’s like three orders of magnitude difference in your employment base, you need different tools. Right. And that microservices and service oriented architecture in general is far more of an organizational design pattern than it is of a technical design pattern. It’s what you do when you can’t do otherwise. Right. Like when you have thousands of developers or at least hundreds of developers, they can’t all just sit and work on the same thing at the same time. They need to be carved up and made independent. And these are fine patterns for that. But there are horrible, terrible, no good, very bad patterns when it comes to small teams. Right. They’re taking on all the overhead and getting none of the payoff.
I don’t even know how we got on that tangent.
Nice children’s book reference, too. Do you have time for another question? Sure.
Shoot.
One of the things that I picked up on again after re watching that keynote, the comment about mathematics and that your disinterest in programming somewhat was related to your disinterest in mathematics. And I wanted to ask about that because I’ve got a daughter that’s in College now, but when she was in high school, she’d have friends over and stuff. And of course, since I’m a programmer and I have a CDs degree, I would ask people, have you considered going into computer science? And I can’t even count the number of kids that have said, no, I don’t want to do that. I mean, programming sounds interesting, but I really don’t want to do the mathematics.
And that just infuriates me because the math that I remember from College, I haven’t been using it every day. Do you have any other thoughts about the requirement of math in computer fields?
I think it’s unfortunate that the Avenue which we have to teach people about software is called computer science. I think right there there’s a fundamental disconnect that is seriously harmful and limiting to the wide range of people involved in the creation of software that we need. Computer science is a very narrow pursuit that really is not day to day relevant to a lot of developers. That doesn’t mean it’s not good to know your own notations. It doesn’t mean it’s not good to know how algorithms are created. It’s not good to know how hardware is put together and how operating systems work and so on. Those are all wonderful things to know about, but they’re not prerequisites to becoming software developers. And in some ways, and in some instances for some people, I think they’re actually detrimental. That the kind of software development that I feel that I do is different because I’m not steeped in CS tradition and thought patterns. And I think that it’s unfortunate that if you want to go to College and learn about software development, you have to go through computer science. I think there’s just something fundamentally flawed about that, and I think it’s limiting a wide array of people who would otherwise do very well in software development from even entering into a formal training program because of that. And I think that we’re seeing a rebellion of sorts against that with coding schools and other sort of focused programs that aren’t about learning how to write your own compiler, but about writing good software. And I think that that pursuit of how to write good software is eminently worthy of serious study and long year education, and it’s completely lacking. There’s an utter void in our educational system when it comes to producing well trained software writers, and I think that’s just a damn shame. So that’s why, in part, that I highlight my own path and my own experience of coming to be a software writer, because it doesn’t follow, at least not fully that path. I have a joint degree in computer science and business administration, but when I say that it overstates the computer science part because there really wasn’t all that much computer science in it. It was more information technology and all the actual computer science bits. I have forgotten the vast majority of those and they aren’t really terribly relevant for my line of I want to say line of work. But that isn’t completely accurate because, for example, the development of the Ruby on Rails framework, for example, does certainly benefit from having lots of people involved who are very steeped in computer science tradition but it also benefits from having lots of people who aren’t that we need sort of a broader array of people with more diverse interests and background and focus to make good software than just a bunch of computer scientists I’ve met have been friends with lots of imminent computer scientists who could teach me all sorts of things about algorithms and compilers and whatnot, but weren’t very good software writers in the sense of the word that I like to stretch, which is sort of writing high level pieces of code in the domain that I write it and business software.
It’s a related but different discipline.
Yeah. Anyway, I don’t want to keep you too long. I was watching catching up on my elementary TV binging last night and a quote came up that was conventional is the enemy of interesting and you’re definitely both unconventional and quite interesting. So I thank you for being on the show today.
That’s very kind of you. Thank you so much for having me.
Thanks, David, for that excellent interview and thank you to Pie Charm for both for supporting the show and for creating a great tool. Again, the link to try the extended trial is testhnico.com pie PyCharm thanks for listening.