Menu Icon

Getting Apps Done

Video Games, Video Jockeys and iOS apps? Oh my!

April 11, 2019

1x
Audio Player 15 Seconds Back Button Audio Player Play/Pause Button Audio Player 15 Seconds Forward Button

Episode

21

David Wood joins us today to talk to us about how he got into development… Hint… I’m not the only one who got my start in development playing video games! See mom! I told you they weren’t a waste of time!

Tune-in using
Listen on iTunes Listen on Spotify Listen on Google Play Listen on Overcast Listen on Tune In Link to our RSS Feed
  • 00:02 Joshua

    Welcome to getting apps done, a mostly non technical podcast with the goal of helping you deliver software because if you didn't ship it, it didn't happen.

  • 00:15 Kellen

    But yeah, if you want to interview or a introduce yourself so we can get to, I guess everybody can get to know you.

  • 00:20 David

    Okay. So my name is David Woods and I've, uh, been developing iOS apps now for quite a few years. Uh, I think if I think back, it's probably somewhere around, um, around 2012 I think I started properly and um, I've got a few of my own apps that I've put into the app store. That's sorta how I started as uh.. a kind of side business. Uh, at the time I was working over in customer insight analytics and data and that side of things in my regular job than iOS was this sort of attractive, shiny thing to sort of start doing in my spare time.

  • 00:58 Joshua

    Shiny things...

  • 00:58 David

    And now it is my full time thing.

  • 01:00 Kellen

    So it started as kind of like a hobby project or a side project. So I project

  • 01:05 David

    Side project... I was incredibly bold with where I found myself at in terms of my career. And I had all these ideas for sort of apps starting to come to to the fore. It was something that just sort of kept nagging at me. And in the end I sort of decided, right, well, okay, if I'm going to actually make some apps I need to get on with this. And that. That kind of required me sort of getting quite focused in terms of, of setting some time aside to actually go and learn ios development because as completely counter to the sort of stuff I was doing during the day and a lot of ways, um, I was, I was working with um, products like SaaS, uh, SQL server, uh, and that kind of stuff. And it's very linear, you know, it's just you make a script to go pull the data and it's like top to bottom, that's it.

  • 01:53 David

    And actually quite throw away code as well, you know, in terms of getting information out of systems, I would just write the script to go and grab that information and manipulate it, transform it, and then the end output is tracked into spreadsheets. And off you go. There's nothing really permanent. And so for me, ios development wasn't just learning the language, which at the time was objective c and and learning that the project format and how you actually bring these things together. For an app. It was also learning concepts around objects or inside to programming and learning things about, um, threading and that side of stuff as well. And all the other things that sort of come with working with mobile as a whole. So yeah, so there is a lot in there actually to get over that line initially.

  • 02:39 Kellen

    So for where you originally, what type of, I guess, how did you learn to program to start with? I mean, he sounded like you were doing a lot of reporting stuff. Was that, uh, the beginning of how you learned to program?

  • 02:49 David

    No, no. So I started programming, so what I, I'm in my mid thirties now and late 90s, like 97, 98. So I would be about, uh, maybe around about 15. Um, I was heavily into computer games, like Doom, Duke, Nukem, quake, that sort of thing. And ID software released the source code for Doom to the internet. I think around about 97-98 and this all sort of kind of coincided with.. I was, I was, um, not long onto the internet as well. And so I was sort of into downloading all of the mods for these games. And, and so when this happened, I was fully aware of this being a thing and I wanted to play with the code that was released. So there, there was this kind of whole sort of set up around it at the time on a windows computer, you needed, um, a development environment that was open source actually to compile most of the, the, um, ports of the code that were going on at the time because it was released as Linux. It was then backwards ports it to, to DOS other platforms. And so I had to sort of download all of this environment to even just get it's compile and play. And then at that point, uh, at the age I was sat there looking and going, well, I don't know how to do any of this. And just sort of started hacking with c code with, with the the files that were in that, that project.

  • 04:24 Kellen

    That's kind of amazing.

  • 04:26 Joshua

    That sounds very familiar.

  • 04:28 Kellen

    That sounds familiar, but I started with web stuff, the easy stuff first. I didn't go straight to trying to read the doom source code.

  • 04:36 Joshua

    I remember downloading exactly that on a 28.8 Modem. It took forever and my parents were constantly yelling at me. Are you on the phone again? Still downloading this! Yeah, I think it took about two days in the end.

  • 04:51 Kellen

    I do you remember the first time I read uh, when they released the Quake source code later, by the time that happened I was a much better programmer and I remember being amazed at how clever all of it was. Like it was a really simple solutions to really difficult problems and that kind of changed my view of how code could work. Like some of the old, you know, the old quake code was pretty impressive.

  • 05:12 David

    Yeah, it very much, I mean there's a lot of reverence for developers like John Carmack I think from, from a lot of developers. And I feel like if I was to sort of sum up my, my view of, of his approach to development. So what I've sort of seen from all of these code releases is he, when he's got a constraint, which... Back then, you know, with Doom and with Quake, there are a lot of constraints in terms of what computers could actually support them and do when he's got a constraint. That is where I feel as a developer, he's at his best and you see, like you say, a lot of beauty in some of the code that is there as well. Um, Doom has got some similar similar aspects to our, uh, still remember, um, and, and just, and even things like how the, um, how the levels are made in the fall formats months that they've got for doing so.

  • 06:08 David

    There are a lot of, a lot of things that that kind of optimize so that when you're firing bullets at the enemies on the screen, for example, the lookups that it uses to sort of calculate whether or not that that you've got line of sight to hit the enemy even, um, it's a little optimized. It's optimized down to how the, the levels of crafted. So you make a level, you've got, you know, that the general kind of design of it and that salt expressed as points and vertices and that sort of thing. It's 2D for Doom. But then there's a separate step to make it work where you compile that level down and it builds all of these look up tables and the app them reads. And then that means by the time the, the, the engine is, is using that level, uh, it's able to shortcut and optimize and, and do these calculations really, really quickly. And that's how come they are able to do this sort of stuff over on 386s

  • 07:05 Joshua

    Exactly. Yeah. I find it kind of strange as like I don't, I don't really know anything about, you know, John Carmack is a person, I only know him through his code. And the things that I've seen and it's like within this one space, like has be kind of an artist to the programmers. Like he definitely treats these solutions and these problems as a type of art. And I don't know, I've always found that kind of fascinating. But...

  • 07:26 Joshua

    Yeah, it was always really elegant in its simplicity. That's what always threw me off because I just assumed there was a lot of really complex stuff going on in there. But the reality is he couldn't do a lot of really complex stuff early on, at least to this day. He's still, he's pushing the boundaries, so he's got to simplify things and find creative and really amazing ways to simplify things down so that the machines can cope with it in the first place. But also because it's a better way of coding. And that was one of the things that I took from that early on in my career was... If I want to make things work well, I need to make them work simply.

  • 08:02 David

    Yeah.

  • 08:02 Kellen

    Right.

  • 08:06 David

    Yeah, very much. Although I do, I do feel like some of the, the um, the solutions that you find, um, over there with, with what he did specifically... For me, I look in a kind of go now I can kind of feel like, well, that would be maybe a couple of refactors down, at least for me with any other things that I'm, I'm coding in terms of some of the, the elegant solutions if you like. Um, there's very much, I sort of feel like, um, this a developer, I can sometimes feel like I'm kind of, I'm carving the solution out of, out of clay sort of thing. You know, you first go of it is, you can see the shape of it. It works. It does what it's supposed to do, but there's, there's like the next level down, if you like, where it said it becomes that that bit more beautiful as it's part of why I like the agile kind of approach to development and that side of stuff is where you get a chance to kind of, um, potentially to, to spend that time and refactor down in certain parts of the codebase.

  • 09:08 Joshua

    We talk about that quite a bit here.

  • 09:10 Kellen

    We talk to a lot of new developers and that's actually kind of a recurrent theme of explaining that your first edition is just that first pass, getting it to function, getting a rough shape, and then you just keep iterating it and pushing against it until you can can refine it to make it simpler and faster and better, more elegant just, and you just kind of keep at that and you get better with that at that over time.

  • 09:31 Joshua

    Yeah, that concept of incremental iteration slowly building up and improving something and not particularly for new developers. It's a really important thing because again, they look at things like I did with Carmack's code early on, assuming that everything is really complex and really hard and they have to figure out all this really hard stuff in one go. Yep. And actually taking it back a step and saying, no, no, just figure out this one little bit of it, get that out, make it work, and then come back around again and make it a little bit more complex or add something else into it. And that's a very powerful concept for them. And for any developer..

  • 10:10 Kellen

    I would say it's kind of opposing features to, you're trying to, you're trying to simplify it, come to a more elegant solution to do all of these things while at the same time trying to add more features to add new stuff and interesting stuff. And so these two competing pressures that kind of create whatever it is that you're trying to create.

  • 10:28 David

    Yeah, very much. And if I sort of think about, um, my current, my current day job, where I'm working in, in a, a company that is producing applications for clients and some of those, um, some of that work is, it's a one off, right? You know, it's, it's a limited, um a limited contracts. You don't get the chance to go back in as a developer and a maybe keep it to writing forever. You know, we've got, um, you've got maybe a couple of cycles of that with some of the really small ones and then it's got to be done. It's got to be closed down. So there's a real, um, as a developer, it can be a real conduct grind to find that balance. You know, you want to do the right thing, you want to make the best product, uh, but equally there's only so many hours allocated for doing so and yeah, I guess

  • 11:20 Joshua

    You have to deliver something in the end.

  • 11:22 David

    Yeah, absolutely. And, and there's an element of, um, in that, in that sense, having to remember that the perfection is the enemy of the good and maybe to be good is all that's really needed there. As long as it's meeting the requirement that the client wants and that, um, it's code that is readable, understandable and supportable, then it doesn't necessarily need to be beautiful. It doesn't necessarily need to be intricate. And that, um, I guess the thing that I'm seeing now after having been this in this for some time now is that you solve a lot of the same problems again and again, but, but for different clients as after a while, what, what can happen is that you end up with a way of doing something that is that bit more honed, a bit more intricate because you've solved this problem before. You know, you look back at what you did the last time round, you have another go at it, it's just, it's not in the same project.

  • 12:19 Kellen

    And those I kind of look at those patterns is why the more experience you have, the more you can charge because you kind of bring those values, you bring those premade solutions to their problems and you can apply those things in a quicker period of time. And so you can, you charge a bit more cause you're at bringing more value with you and within the same time and within the same resources.

  • 12:40 David

    Exactly. Yeah. Yeah. And, and that's, that's the thing, you know, when, when I can do this for you well and do this for you relatively quickly, that doesn't, that, that actually means that the value of what I've done for you is, is more, uh, uh, yeah. It's not always something that, um, the uninformed clients we'll see. You know, this assumption if something's been cranked out quick or whatever, that, that, that means it's lower value.

  • 13:09 Joshua

    I've seen a lot of that as well. Uh, clients will want to either, they think that because we can do it quickly, it's not worth as much or they think that because something else is cheaper, that that's got to be better. Or somehow there's a lot of that. There's an engineering saying, how does it go? The engineering company calls in or repairman and he spends about five minutes looking at it, then bangs on something with a hammer and then says, okay, that'll be a thousand pounds. And they said, we only spent five minutes and he banged it on a hammer. Yeah. But I knew where to bang it with the hammer.

  • 13:45 Kellen

    Yes, exactly.

  • 13:49 Joshua

    And there's a lot of value to that and people don't understand that experience and prior knowledge of things is what they're paying for it. And it's not necessarily the hours that they're paying for.

  • 14:01 Kellen

    Yeah. And that's, it's hard to measure value .

  • 14:03 David

    In, in software as well that there's this kind of other value to it, which is about, um, I feel like it's, it's about building things in such a way that you don't preclude, um, changes in the future that you can't quite future proof for everything. But there are ways of developing things intricately and developing things quickly that might paint yourself into a corner if you wanted it to change or expand upon an app or whatever later on. So there's another side to experience as well, which is about laying things out in such a way that you're not, like i say, painting yourself into a corner if changes happen later on. And that is a quality I think that is quite often missed as well in terms of the sort of value proposition and that side of things. You know.

  • 14:52 David

    It's not just giving you a good product and meeting all the requirements and that side of things, but equally when you want to change the screen here at this feature in there, it's not going to be paying down a load of technical debt ahead of it or, or whatever. You know, we've built this in such a way that is possible to just go and do these things that, that, that ok, yeah, the app didn't do that in the first place. But there is a point that it can be edited out nicely to go and allow you to do this.

  • 15:19 Kellen

    And that balance between simplicity and features, being able to have those options in the future while still it being simple and easy to understand and a new person coming in and being able to look at that, that's a balance that kind of comes with time and practice.

  • 15:32 Joshua

    That's a hard one to explain to people as well who are buying something and it's not just software development. Houses are a really great example of this where a house that is really well built can cost a fortune and I as a house buyer really wouldn't understand why, but I've certainly lived in some houses that were cheap that now that I've lived through it, I understand exactly why they were so cheap because the work that went into them was not that well thought through. It was just churning things out. Uh, particularly you'll find in new build neighborhoods where they're all the same house, that just doing it as quickly and as cheaply as they can. And that's fine until the moment you realize something has either broken or you want something new or something different than what you've got currently. Any call in the electrician or somebody like that and they say, oh, this is a mess. It's going to cost a fortune to fix this order, replace this or do this. Whereas in some of those other houses where everything was well thought out and it's really easy to swap things in and out they come in and Oh yeah, this is a doddle no problem at all. And for me to understand that value, I didn't really get it until I experienced the negatives of those things. And it's much the same for people who are buying software. They don't get it until they understand it from firsthand experience.

  • 16:46 David

    Yeah very much. I think I can actually rely on an example of something where we managed to kind of land that, that perception with a client. And we, um, there is a, a project which is kind of ongoing that I'm working on. And so we agree things out. We're working sprint by sprint with, uh, with this client and we're actually working really quite collaboratively with them as well. There's project managers on their side as well as us and that sort of thing. And it's working really quite interestingly in that respect. But one of my, we had this conversation where I sort of called out, um, that we had to pay down some technical debt if we wanted to support features that they were thinking about on their roadmaps, sort of a few months down the line and one of their, their people sort of said, we can't call it that if I take that to internally within my, within the business, none of the people around me, none of my managers are going to understand what that is. And it sounds really negative technical debt sounds awful. That sounds like, you know, we've been running up some sort of like cost over here that, that, that we shouldn't have been doing.

  • 17:58 Joshua

    It's the bar tab for the IT guys!

  • 18:00 David

    Yeah. One of my coworkers ...

  • 18:00 Kellen

    You can hear us laughing...

  • 18:04 David

    Exactly yeah... That sort of like not really been able to understand what what it was. And one of my coworkers kind of spun it and sort of said, well, could you call it technical credit?

  • 18:19 David

    There was a sort of pause for a second. As everybody kind of like had a... Maybe a slight cringe at some of the cheesiness at this, but that worked and they named it that and that actually got it into the mix and we were able to kind of go and do this work then. And what, what that's meant for me, that, that give me back time to, we had this whole sort of system within this app that was um, it wasn't storing data in the way that I wanted it to be signed and needed a local database inside of the app itself, uh, to sorta kinda go and then support our flexibility in terms of what the app is doing across multiple different parts of the app. Uh, we, we had to need to sort of share this data out between different screens and being able to access it and have components working independently of each other as well.

  • 19:10 David

    So doing this work sort of supported that. So we, we we um, yeah, we, we, we did our technical credits, we've paid our technical debt, got this all in. And what I've kind of been king to do since then is kind of points out the value of this because it can be really intangible to a client. And so we had a situation a few weeks ago where something came up. We needed to get something in really quick for them. And I was able to turn around this, this specific thing, which could have been quite complicated beforehand. I was able to turn it around in a matter of an hour or so, get the change in, actually update the building and get that over for their guys to test. And that was really quick. Thank you. That's that as awesome. And I said, yeah, it's because we paid that, that technical debt earlier, earlier on in the year, it's because we did that and that let them kind of feel that value of it. Uh, that, that, that's been quite a positive for many of you don't get that opportunity with every client. But it's, it's been good to sort of have that with this one. Uh, and I, I kind of hope as well, it kind of built a bit of trust that, you know, we, we know what we're doing and it's not just the developers asking for more time, you know?

  • 20:25 Joshua

    Yeah, exactly. Do you kind of have to build that up with them and help them understand what the value you're providing is and when you ask for something that they're going to get something out of it.

  • 20:34 David

    Yes. Yeah, definitely. Especially when like, you know, the, the, the first go round of this project was to kind of cut a, an MVP sort of version of the app so that they could just test it and just it in front of people to play with. And, and so at that point, you know, focusing on anything other than getting features was not the priority. It wasn't where the project was at. Yeah. Uh, and this, uh, yeah, there's definitely a sort of building up trust and that side of things as well, but the thing comes and, uh, it can be, it can be a tricky one. I mean, I see this as a developer, um, but equally I kind of care about the project as a whole. I don't just care about chucking out code, you know, there's more than that that for me with it. So, yeah, I'm sort of mindful to, um, I guess to say what is necessary to make the development go as well as possible, but also to kind of get the client to understand, well, what does that mean? You know, and yeah.

  • 21:30 Kellen

    Do you think I'm going to be using your, uh, your technical credit, a line in the future, just as an explanation of you're paying in, so you'll have credit in the future to do all the features that you want. Like that's, you start off with some and then you build up more. And I think that's a, that's a good analogy. It's a good way of approaching the concept of technical debt is really the opposite. You need to fix these things so you can do more.

  • 21:52 David

    Yeah, yeah, absolutely. And it reframes it, I think in such a positive way, you know, you're thinking about doing this ahead of time rather than technical debt is this sort of monolith and stone around your neck. You've got to get rid off before you can go and do the fun stuff. So

  • 22:10 Kellen

    yeah, and this kind of reframes it as, oh, this is just the, the lead up for the fun stuff. This is the job you work to buy the new car or whatever, you know, to, it's a similar concept that we're aware of.

  • 22:19 David

    Yeah. We've now reached a stage as well where it makes it easier to, to kinda do some of this stuff. Iteratively as well rather than just ignoring it so I can call out and sort of say, hey, we've got a bit of time left in the sprints or whatever I'm going to fill it with, with these technical credit items, which will then support what we want to do next month, next week, next time round. Yeah,

  • 22:42 Joshua

    Yeah. I like that. I'd never thought about it the other way around. I, I, we try to find nicer ways to portray it other than technical debt, but that's actually a really good way of phrasing it. That makes it a very positive thing that people understand. You know you have to do some work up front to get anything good. Nothing comes for free. And having that concept in makes it a lot easier to sell that to the business.

  • 23:04 David

    Yeah, absolutely. I like to say I've been looking for the opportunity to kind of, um, without laboring a point or whatever, but, but to communicate back to them, we were able to do this because of that and so that they can then sort of start to make the connections between things that they wouldn't otherwise know, you know? Okay. Okay. What's uh, moving the data model into a local database mean? You know, the app behaves exactly the same afterwards. Uh, but then when you're able to say we're able to get these extra things in on the screens and that was actually supported by doing this. And it also means we get these other bits for free because the database supports this other activity. You can kind of start to makeit more tangible to them.

  • 23:46 Kellen

    Yeah, s programmers. We look at those things as like prerequisites or dependencies of, but from the opposite side of the, you know, the folks who were looking at the finished requirements, they can look at it backwards instead of going, oh, this paid for the thing that I wanted. And I think that helps a lot to, to communicate those things. So I'm going to be using this in the future. Thank you.

  • 24:09 Joshua

    Now, programming clear the isn't just a job for you. It's something you really enjoy and you're fairly passionate about. You've got a couple of side projects you're working on that are programming related, haven't you?

  • 24:20 David

    Yeah, I have. So I uh, outside of programming, a couple of other things I've got going on is that I, I run a podcast, uh, over with, um, a friend of mine back in the UK. I'm from the UK, living in New Zealand now. Uh, so that sort of related and in the area and that podcast started off about being independent ap development. Um, little plug it's Waiting for Review, waitingforreview.com. Um, but, that sort of as well as in, it's in the same sort of sphere. And part of that is that, um, Paul, the reason for that being about independent app development is the projects as you mentioned just then that the actual things I'm building and what I've got is I worked on a um, a video mixing application is one of my first apps that I put into the app store.

  • 25:12 David

    Uh, that, that went into the app store or roundabout it's going to be three and a half years ago I think now. Uh, so I took my time, I learnt iOS development made load of kind of prototypes and random projects and this is all happening sort of a side business. Like what not even a business at that point. Just something that was hacking a while and then eventually kind of focused and managed to get this app together and put it to the app store. And that's still in existence. So that say I'm a video mixing app that lets the user manipulate video in real time. Uh, so you have like, it's like a uh, a DJ sort of set up. You've got a concept of two channels of video and a cross fader between the two. And that lets you, whatever you mixing on the device you can send to an external screen and then use that as a backdrop for a band or a DJ or that sort of environment.

  • 26:05 Joshua

    I found that quite interesting when we met, that was fairly new for you. That was a couple of years ago now. In fact, we met at a coworking center in England and we'd met a couple of times outside of work and I came home, told my wife, yeah, I, I'm at one guy, I think we get along quite well. We should, uh, start doing some things and then I meet him somewhere and he says, yeah, I'm moving to New Zealand now. Uh, but I was very interested in the app at the time because I hadn't seen anything quite like that before. And I thought that was really interesting. And that concept was something new to me. I can't say I go to clubs very often, so I hadn't seen anything quite like that. But I've seen things like that at concerts. And it never really dawned on me to think about what goes on behind the scenes to make that happen.

  • 26:50 David

    Yeah. It's, um, it's something that I used to do. So yeah, having being a father and having two young boys, I don't get to go clubbing in the same way as I would have done quite a while back, but oh, quite a while back.

  • 27:04 Joshua

    It's odd how that works.

  • 27:05 David

    Pre kids... All of that. Yeah. I was, um, for a little while I was a, uh, what, what is termed a VJ. So video jockey, somebody mixing video for usually in a comp company meant to a DJ. So somebody else is running the audio, all have been crammed into the side of a Dj booth with all of my video kiJ. Um, kind of trying to keep pace with what the DJ was doing and mixing video live.

  • 27:32 Joshua

    And this is why you wanted to make an iPhone app because yo had to cram it all in there.

  • 27:35 David

    Actually. Yes. Literally. Yes. So way back when, that day we're talking 2004. Um, and at that point in time what was happening was that there were, um, Mac and windows programs for running visuals that were okay. Um, but the weren't, they weren't necessarily that stable. So you ended up with a situation where you would do a gGig but you would have a hardware mixer in the middle and that will provide some sort of like kind of fail over a few computer crashed out and usually you would have like, uh, a couple of DVD players or other sources routed through that. And so the level of kit would be, you know, a couple of DVD players, my video mix, uh, uh, my computer and any midi controllers and stuff like that to control the, the, um, the software running on the computer. So there's a lot...

  • 28:24 Joshua

    All on your lap...

  • 28:25 David

    Yeah... A lot of kit, a lot of, usually it sort of ended up in this sort of situation of, um, of kind of like flight cases stacked up. And yes, it's certain gigs, like say the space, you would have you be crammed in a in a booth. DJ would sort of look at you like you're getting in my way mate, what are you doing.

  • 28:46 David

    I know a lot of stuff to haul. So fast forward a few years and I've got kids, I'm not doing that anywhere near as often. Video Mixer is sort of sat gathering a bit of dust, but I still kind of want to play with the, the art form and mess around with it. So I looked at the APP store and this is sort of, I think the inkling for this for me kind of came around about when the iPhone four was released. Um, possibly the 4s, whichever one of them sort of delivered HD video and I thought, Oh wow, okay. That's, that's higher video than um, in terms of resolution than anything I used to mix. Uh, so mixing wise, we work with sort of quite low resolutions at the time because of where computer's capabilities were at. Uh, so it's quite common sort of mixes, sort of 320x200 resolution video 640x480. Um, and uh HD is quite a bit more than that. So I thought, wow, the device phones are getting to a point where they can do better video than I used to mix with on a laptop or even at one point we will, I'm holding a um, a full desktop setup to gigs as well.

  • 29:53 David

    I thought... Is there an app? And I had a look in, there were, there was an app, um, and it was, it was awful. It was a rubbish app..

  • 30:04 Joshua

    The best apps come from that. This one sucks. I'm going to make a better one.

  • 30:07 David

    That was the motivation. So at that point I saw that and it's like, okay, what am I going to do to, to make this happen and download it Xcode, how to look at some tutorials, got a sort of Mac for dummies for dummies book called whatever. Right. And it just didn't stick because of what I was saying about before where the talk of programming I've been doing day to day in my regular job just wasn't that sort of programming. So there's was a lot to kind of get my head around and and mapping it out. I knew the technologies that were being used in desktop VJ software because I've been part of that scene, you know and and there was a transition point from software video effects over to GPU based ones.

  • 30:49 David

    And so I knew that I was going to need to learn something like Open GL just to sort of make the effects work and that side of things happen. And so it wasn't just one technology to learn. There was learning iOS as a stack and the thing in a, in an of itself learning the paradigm of objects or insights you programming and getting used to that as well as technologies like working with a foundation to actually get video frames out of video files all the way through to open GL then to run the effects. So developments of the app itself took, took quite awhile because each kind of stage of it, if you like was was me learning this new paradigm or technology.

  • 31:31 Kellen

    It's cool though that you, you're kind of sharing this experience though with folks who otherwise wouldn't be, you know, I don't have a stack of VJing kit to haul around to places, but now I can open up my phone and try it out myself that that's uh..

  • 31:44 David

    Exactly, yeah.

  • 31:44 Kellen

    A great thing.

  • 31:47 David

    And I've found that, so I did this app for me just because I wanted to play with something better than what was in the store at the time. And then what's happened over time is I put that together as a proper release and kind of went after that as a small business idea. And it's still, it's still selling now even. So that sort of continued since then. And what I've found is that it's sort of found its audience or it's market if you like. And thinking about it now, it's logical as to what that is. And it is, it tends to be people who just wants to have a play or it tends to be people who are beginners within the art form and so it then provides a really low barrier of entry for those people. A lot of the software for Mac or for PC is super expensive. You know, you're talking upwards in in times of um, British pounds. It would start, some of the software starts at like 200 pounds. It's not a cheap investment.

  • 32:44 Joshua

    No, I think... smartphone apps in general, I that it's one of the things that I found really amazing about them is they make things like that much more accessible to people as it was. One of the things that really attracted me to the web and mobile app seen is that because it's not this old monolithic, you got to have all of Adobe stuff and all of these things. Small little apps can give you a taster or open your eyes to something new and give you the ability to try it out before you go invest in hundreds of pounds of equipment or even thousands of pounds of equipment to get into a new hobby or a new interest.

  • 33:18 Kellen

    It can show you the highlights of that hobby or that interest can show you. You're kind of like the, these are the really cool things that you can sort of do. And then as you get more interested in it, you can get more kids to do better or you know, more detailed or, you know, it's a, it's a nice introduction to art forms like you said.

  • 33:36 David

    Yeah. Yeah. And I really appreciate what the app is sort of done for people because of that as well as kind of given this, this other site that sort of a bit more, altruistic or positive if you like, than just I wanted to make an app for me. Uh, and that, that's been kind of fun. I remember the days of sort of being a beginner in the art form and equally sort of since then, because I've not been pursuing it professionally or been as immersed into it as people who are, you know, running gigs every weekend you kinda get to feeling slightly excluded after a point in terms of some of the, uh, the community around it. Uh, cause you, you're not playing with the big boys will have for you. You want to phrase it, you know, a lot of these guys do phrase it just like that. And again, to sorta make and have an app that lets almost any body kind of have a play and a go.

  • 34:22 David

    It's, it's quite, uh, it's quite fun side of it.. As an element of it sort of feels almost slightly subversive to you as well in a sense of flight. We'll high, you know, uh, yeah. Anybody can actually do the bare basics of, of, of this and people don't need to care about all of the sort of really geeky ends of the detail. But a lot of these guys do. And it's not that that's not important, it's just that it's not knowledge you need to have upfront when you're first starting. Uh, but the way the communities are run, it can be kind of quite gate kept at times and a lot of these people do sort of sort of thing to think, you know, you need to know your resolutions, you need to know all of this, that and the other. Just to put some video on and have a play. I feel like it just, it just isn't like that in reality and over the right application or the right piece of software, you can push that complexity down a level and it's still there if somebody really wants to get into it, but you're not using it stuck between that person just putting some video up for mates gig.

  • 35:17 Joshua

    Absolutely. You say the app did that, but actually you did that by creating the app in the first place. But we really appreciate you coming on the show. I actually been really interesting in general, we've met before, but there were a lot of things in here that I didn't know before, so it was fun to learn that as well and to catch up a little bit.

  • 35:35 David

    Awesome. Great to talk with you. Yeah, thank you.

  • 35:38 David

    Yeah, great to catch up with you, um, feel free to drop me a line again, always up for this sort of thing.

  • 35:44 Joshua

    Absolutely. All right. I will put up some transcripts at gettingappsdone.com. Please be sure to check out my website joshuagraham.info and check Kellen's website at piffner.com And absolutely, please do check out David. We will put some links in the transcripts so you can find his website, his podcast, and his applications. And if you have your own story about how you got into software development, we'd love to hear about that because we think everybody has their own unique path and it's amazing how people do get into software development and we'd love to hear about your journey. Until next time, thank you for listening.

  • 36:19 Kellen

    Cheers.

  • 36:20 David

    Catch you later.