Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/modernization: out with the old
66 Plays1 year ago
We discuss legacy systems development with Dillon Courts
Recommended
Transcript
Legacy Systems and Estimation Challenges
00:00:02
Speaker
I think you do get better at estimating with time in the industry, but nothing's ever really going to take the place of having to deal with legacy systems. That business logic is not standard. The analogy I use sometimes is is, I can't give you a good estimate because you're you're basically giving me a book to read and that book is full of math problems. And each one of those math problems is a varying degree of difficulty. And I'm not going to know how difficult it is to solve until I've actually gone through and looked at each math problem.
Podcast Introduction
00:00:36
Speaker
Welcome to the Forward Slash, where we lean into the future of technology. I'm your host, Aaron Chesney, with my co-host, James Carmen. James, who do we have with us today?
Guest Introduction: Dylan Quartz
00:00:46
Speaker
Today we have Dylan Quartz with us. Dylan, maybe tell us a little bit about yourself. Yeah, I'm the Collaborative Platform Engineering Practice Lead. ah Platform engineering means that I specialize more on the DevOps and developer experience side of things. So I focus on making sure that developers are capable of doing their doing their jobs effectively and efficiently and trying to make that ah a pleasurable experience for them. Nice. How long have you been doing the the technology thing?
00:01:17
Speaker
It's probably been over, it's been over a decade now, so like 12 years or so. Where'd you get your start?
Dylan's Journey to Programming
00:01:24
Speaker
So I got my starts. ah Way back coming out of college. I wanted to do the the video game thing, but I guess it goes back further than that. I Guess I kind of grew up with the internet, right? I'm a I'm a late 80s, baby So I came of age with with the internet. So I was always messing around so like Napster and LimeWire and AOL instant messaging Yahoo chat rooms like I was spending a lot of time doing that kind of thing and
00:01:56
Speaker
But I never really thought about programming. In fact, I wanted to do dentistry was my first thought. I really enjoyed going to the dentist as a child as weird as that was. I think I just had a really good pediatric dentist. But I went immediately to Rudolph there. I did too. In the in the ah the elf that I just want to be a dentist. Yeah, that's funny. Yeah, that that dream died for me when I went and shadowed a dentist. I had a friend whose dad was a dentist. And it was just a ah miserable experience, like what it looked like he had to do day to day. And then he just being inside everyone's mouths, right? And then he specifically had an older lady come in who
00:02:41
Speaker
who was terrified of the dentist and probably hadn't been in about a decade. And she had some cavities and she was just very, very anxious the entire time had to use the gas on her. And it just, it just didn't look like something that I wanted to be a part of long-term. So that's when I made the decision to not do that. But circling back to programming, my basketball coach, my sophomore year is the one who, who told me that I should try it out. And he happened to be the, the programming instructor at my school. So my junior year is when I tried it and we started with some Java, learned some Java and i I fell in love with it. I really enjoyed it. And then my senior year I was able to do two separate classes. They had like an AP class for computer science and then they had a, it was called computer science too, but it was really do whatever you want and make your own curriculum. So I chose to go ahead and make a video game at that time, my senior year.
00:03:35
Speaker
And I was really into Halo at the time. I think Halo 2 was the the big game that had come out. So I decided to try to make like my own replica of of Halo using C-sharp. And I don't even remember what the game framework was back at the time. But I remember like going out and searching for like clip art or or art like animation strips on Google Images and putting that together. And like the first time I was able to get like a little character of Master Chief, like animating across the screen was like nirvana for me, right? Like my eyes lit up. I was i was super excited about it. Trying to think if I've had that spark doing software development, like since that first time, right? Like it's, it's hard to, it's hard to replicate that. So that was really cool. I spent an entire year developing.
Early Career in Game Development
00:04:21
Speaker
a game and then I ended up taking it to a game competition at Miami University here in Ohio. And I won that game competition, which was cool. So that's when I decided I wanted to to go forward with that. So I went through school at Ohio State and then ended up working in game development at a small company in Columbus who specialized in casino games on mobiles. They were one of the first They had one of the first apps in the App Store. It was a Blackjack app. It was one of the first apps, one of the first 100 apps, I believe. And because they were so early and the way the App Store worked, it was somewhat of a self-fulfilling prophecy that like once you were at the top, you stayed at the top. And so they were able to maintain revenue coming in off of that app and a
00:05:06
Speaker
It was a slot machine app for five or six years. So I came in as an intern and I was allowed to to make whatever I wanted my junior year after my junior year of college. And so I made this like side-scroller beat-em-up game called Sarge, which was pretty cool. So we... you controlled them with like ah an on-screen joystick and you could punch and jump. It was like a platformer combo and you beat up these aliens and one of the other interns we were working with had some connections on Ohio State's campus and we rented out a like audio studio and we went in and did voice recordings for for the for the characters and that was really fun. We tried to sell it for like a $1.99 or $0.99 or something and it didn't really get bought so then we made it free
00:05:51
Speaker
And at the time, there were there were websites out there that would watch for games going free and then put them on a list. So it got put on a list. And when that happened, it hit the top 100 free games for about a week. So I had like over, I think it was over a million downloads on that particular game and it's not supported anymore, right? But that was a really cool experience. And then I went on to work with that company for six or seven years doing Doing game development, did everything from more Blackjack-type games, started getting into some server-based games. So like casino games and specifically slot machine games that were more server-based. So you would like hit a button on the screen to spin your slot machine. And that would hit our server. Our server would calculate your result. And then we would send it back down. And then the the screen would be responsible for
00:06:39
Speaker
painting it and making it look like you know that was randomly coming up at the time, but that was all predetermined you know three or four seconds earlier based on the result from the server. So like trying to come up with different algorithms to to create different slots slot machine type results was fun, and trying to make sure that the return was correct, right? Because you can't have like a return over 100%, or that person's not losing credits. And that was the whole way that we made money is you lose credits, and then you had to buy more credits in order to keep playing. But it wasn't real money. It was all fake money. I was never really able to figure out like what the profile was, the type of person that was willing to spend money to do like fake
00:07:17
Speaker
right to to get fake returns and fake earnings, but people did it. So it was fun. It was a really small shop. we I hadn't hadn't had any experience like on the infrastructure side of things. That's where I got into that. We ran our own private cloud.
Building a Private Cloud with OpenStack
00:07:34
Speaker
ah Containerization was like starting to come of age, but before that it was trying to figure out how to replicate some of what Amazon had done with AWS. and the infrastructure as a service. Well, we wanted to run our own private cloud and enable us to spin up like virtual machines on demand instead of having to go configure them. So we put together like our own private cloud built out of, it was like 20 different servers. It was just commodity hardware. And we bought these five IKEA cabinets with like four drawers four drawers each. And we put a put a computer in each one, which was our server, right? Connected them all together and we ran the OpenStack software on top of it. so
00:08:11
Speaker
I was a part of that. That was really cool being able to see and be a part of like getting to a place where it's self-service to stand up a virtual machine was really neat. I got my first exposure to configuration management tools. Like we use Chef to set up all of our different virtual machines with the dependencies we needed. We built an entire micro microservices architecture. I use kind of quotes around that because it was only a single database that backed all of it, but we did all that in Python. So that was really fun. As I mentioned, really small shop, only like three or four of us. So I wore a lot of different hats there. I think I published 20 different games while I was there for six or seven years. We did some fun, like endless runner type type stuff too. When Flappy Bird was all the craze we were trying to figure out, we challenged ourselves at one point.
00:09:03
Speaker
to figure out how to put out a game like once a month. like What's ah like a one month cycle? Could we get a game out? And we did it. Three months in a row, we put out a game that was like about the depth of Flappy Bird, if you remember what that was, where you just like tap on the screen. right And you're just going through these obstacles. And so you're just endlessly moving. left to right across the screen, and there's obstacles in the way, and you have to make your bird float up and down to get past the obstacle. So it was like that level of game, so not a ton of depth, but it was fun. My favorite one we did, I think it was called Block the Rock. There was this
00:09:35
Speaker
character who it was like set in it was supposed to be Pompeii I believe and there was this like Roman looking guy running down a mountain and in the background the the volcano was exploding and there were all of these rocks that were falling trying to hit that character as they were running down the mountain. And you would have to try to draw a line above him to like drop to block the rocks. But you could only draw so much line before your meter refilled, and it got more and more difficult as it went. That was probably my my favorite like little one that we did that was a one-off, quick one. But anyway, towards the end of of that career, or that part of my career,
00:10:15
Speaker
we We started to have have trouble with some of the other larger companies like AAA game companies got into the space. They out competed us on marketing big time, development resources big time and we were just having a hard time staying afloat and bringing
Joining Caliberty for Growth
00:10:30
Speaker
in the revenue we were previously. So things were things were slowing down and I was realizing that I had gotten really good at releasing software and like building things and figuring out how to do that. But I had really hardly any classical training in terms of figuring out in terms of um Like good good practices, right best practices around software engineering. I hadn't really had any any exposure to that. So that's how I ended up at Caliberty. I was looking for a company that specifically specialized in that so that I could surround myself with folks who could help me learn and grow. And I've been here for six years now. So how did your parents ah take the news when you broke it to them that you wanted to build your life around making games?
00:11:16
Speaker
I mean, they didn't understand it, right? They never understood why we would spend hours and hours in the basement when I was in high school doing LAN parties, playing Halo or whatever. like I don't think they ever really understood it, but they they gave us enough rope right or enough of a length to go do what we wanted to do. I think they figured it's worth trying trying things in your 20s, right? See what you so you like, see what you can do. You got some time before you really got to buckle down and have a family and do you need a support? If all you're worried about is yourself right now, then go take a chance. Why not? So they were they were relatively supportive. So I'm guessing the rest of your family is not technical. My parents are not. I've got a younger brother who is and a middle brother who also is not.
00:12:08
Speaker
What do your parents do? So my parents, my my dad works in the construction industry. He works mostly in like framing and and drywall. So definitely a different industry than software development, for sure. like You both build things, I guess, something to that, right? Yes, we both build things. No doubt about that. It's always interesting talking to him about estimates in the software space specifically. He he has a hard time understanding why estimates are are so difficult for us to come up with from his perspective, right? he He gets a plan from an architect. He knows what the square footage is of the of the building.
00:12:54
Speaker
He takes a look at that and he's like, okay, I know I need to hang half inch drywall. I can break down based on the square footage of this room and how high the ceilings are. It's going to be, you know, a hundred sheets. I know my guys can hang about 10 sheets an hour. Don't hold me to these numbers. So I can, I can break that down, right. And give you a pretty good range for. for getting that done. But software development is definitely a little a little different, right? there's There's an art to it. I think we're a fledgling industry a little bit. We haven't been around as long. We're not as mature. There's not as much standards, right? Like we don't really have the concept of half inch drywall or or two by fours. Everything's built a little bit differently. So there's always a lot of of learning. I think when you go into, especially a legacy environment,
00:13:41
Speaker
trying to figure out how they built things. And it makes it makes a lot of sense. All of these organizations, as as technology has progressed, like business hasn't business needs haven't slowed down. So whatever was available at the time to solve the problem, they might have they might have built their applications or their infrastructure out of in order to to meet those business needs. But then technology hasn't stopped evolving just because it is such a such a young industry It's only been around about 50 years. So the there's not as much standardization yet I mean, maybe that's something we'll see in the next 50 50 years or so Maybe we'll start to standardize on a certain set of a programming smaller set of programming languages that everybody uses But I don't know we'll see it it still feels like it's pretty young.
00:14:30
Speaker
So do you you think that as languages standardized to maybe like a core set of languages where maybe you only have a few different options, like using the building example, you know, wood studying versus metal studying for your walls, do you think that our estimates will get better with that? Or do you think it's more time in the seat and experience in the industry that's going to lead us to better estimates overall? I think it's both. I think you do get better at estimating with time in the industry, right? I think that definitely helps. But I do think standardization is a big ah big part of it. If we weren't able to get to a place where, like you said, wood or metal framing, like those are your only two choices, you you can get very familiar with both, you can be very proficient in both, then it's a lot easier for you to to estimate. But nothing's ever really going to take the place of
00:15:30
Speaker
having to deal with legacy systems until even even legacy systems that are built with a standard framework or a standard language that you're very familiar with, that business logic is not standard. You still have to read it and comprehend it if you're going to work with it before you can make changes to it. The analogy I use sometimes is is I can't give you a good estimate because you're you're basically giving me a book to read and that book is full of math problems. And each one of those math problems is a varying degree of difficulty. And I'm not going to know how difficult it is to solve until I've actually gone through and looked at each math problem. And so it's really hard for me to estimate without without spending the time to do that up front. Yeah, working with the legacy system is kind of like the movie, The Money Pit, right? it's it's a you You give that initial estimate two weeks. It'll be two weeks. And then you get into it, things start to happen. You're like, whoa, this is
00:16:26
Speaker
way different than what we thought, or we found that, you know, the wiring behind this wall is ancient and a fire has, we got to go and replace that type of thing. And then that just moves your estimate time and time again. And and it's just another two weeks on top of another two weeks. Yeah. and i I don't know how you solve for that. Sorry, James. Good. I know. I was going to say, and and then at some point the bathtub falls through the floor and you can only think you can do is stand there laughing at it. Yeah. Yeah. That's maybe Dylan has never seen this movie. He's, he doesn't look like he gets the reference. Yeah. Well, you know, which movie is this for an audience? The money money. The money's called. them yes Tom Hanks. And I don't even remember who the other person was. Oh, uh, it what was her name.
00:17:14
Speaker
Unimportant, but yeah, it was, uh, not that she was unimportant, just that it's not relevant to the conversation. So what would be interesting is, you know, like you mentioned like the standardization stuff, Dylan, like, and I don't know, i mean it'd be interesting to investigate this. Like back in the day of construction, did did did people go, you know, attempt their construction projects and they're like, Hey, what if we, don't use wood for these you know these support structures.
Resume-Driven Development Discussion
00:17:46
Speaker
and Or maybe we don't do two by four, we do three by eight or something like that. like ah did Did people just get creative and like decide, hey, let's do something different every single time we build something? I don't know. That would be an interesting thing to investigate. Because that seems like what we do in software. It's and like what we want to do. ah That's an interesting take. I'm trying to decide, like do people even have the capacity to do that?
00:18:12
Speaker
And ah it's, there's more risk back then too, right? Like you probably don't want to try out something brand new if you're trying to build a house for your, your family to live in. Like, do you really want to take that risk? So maybe that's a luxury software developers have. And we're working for other companies and they want to build something, but hey, we, we also maybe want to learn a new technology so that we're more useful in the future, you know, resume driven development. Definitely seen plenty of that. Well, I think it starts from education too. I mean, you've got, trade schools and you know and a master and apprentice type a system set up in carpentry and that kind of thing that kind of teach you the way that it's been done and should be done. And there's not a lot of that
00:18:58
Speaker
structure that we see in, in software development. A lot of times you come out of school, you're thrown into a job and just expect to know how to do it. And so there's a lot of self-learning that has to happen. You know, you find certain places that do foster to, all right, we know you just came out of school. We're going to put you underneath this guy that knows his, knows his way. And he'll kind of, you know, walk in his footsteps and you'll be okay. Yeah, I couldn't agree more with that. I don't, I can only speak to my education, right? Like I have a four year degree in computer science engineering, but I was taught next to nothing about best practices and how to develop software. I was taught how computers work, like how program languages work. I built a compiler. Like that was part of my curriculum, but no one ever told me, yeah, your code is good or yeah, or your code is easy to read or it's clean. Like that was never part of the conversation or part of the criteria that I was, I was graded on going through school.
00:19:56
Speaker
But you knew the big O notation and how to how to say how long it was going to take this thing to sort a list of numbers, right? Yes, yep. And I learned some so sorting algorithms. I don't know if I could recall them all, merge sort, quicksort. I remember some of that. The bubble sort was always my favorite. Yep, bubble sort. Just because it had bubbles.
00:20:18
Speaker
Yeah, for sure. I think another thing, um James, you mentioned like people trying things. I think there's like the the aspect of it being virtual. like You can't see what we're working on in terms when we're doing software development a lot. so I do wonder if people are are more likely to ask for changes. like Your stakeholders are more likely to ask for changes because they they can't they don't have a good concept of how difficult it is to make a change. and it's It's hard for us to explain it too. Sometimes it's super easy. like Our stakeholders might just want a button change from green to blue, but sometimes it's super difficult. I think they're asking for something simple. right like i just want my Can just move your my my login page further in the flow?
00:21:02
Speaker
well that's going to take me you know three weeks to do it. Well, why? That's really hard to explain. Whereas like if you're building a house and you've already put your put your second floor on, it's going to be really hard to to restructure that and move your move your bathroom to the other side of the house. right like No one's going to ask you to do that because the plumbing stack's already in place, and they understand the costs associated with that. And that's kind of like those restoration things that you see on the TV shows. It's like, oh, well, we planned on putting a bathroom here, but we didn't realize that the plumbing stack is on the other side of the house. So right there's there's no way we can do that. um And that's that's kind of like one of those things. I also i also kind of, when talking to stakeholders, you you have to change the way you speak. Like if you're telling another developer you know something, but then you have to talk to a stakeholder about the same thing, you have to use what I call manager speak.
00:22:00
Speaker
and put it in terms that they'll be able to understand without getting too technical in losing them. Because and is all of us have known like that person you start going off on a technical tangent and you just see the eyes roll back into the head and they just kind of go into like zombie mode because they have no idea what the heck you're talking about. Yeah, you have to build your analogy repertoire. It's so incredibly important if you want to be able to have those conversations effectively. I tend to fall back on the construction analogies quite a bit because I find that they can be universally understood, but it is so important. I do the same. As a matter of fact, I just gave a talk on the house building analogy for software engineers. Yep.
00:22:46
Speaker
It's definitely a natural one. it's It's the classic, right? That's kind of how we always do it. But it is interesting how theyre you know there may be some parallels, but there's also, you know as we were pointing out just to this conversation, that it really really isn't the same in many ways as also, right? I mean, it's you're dealing with tangible physical things when you're building a house, but in the software world, we're dealing with virtual things. So yeah. And that crosses over even into the engineering aspect of of our work. you know we We don't operate as traditional engineers in many cases. like yeah like Dylan, how how have you seen that maybe the way we operate as software development teams might be different than, say, ah your standard um engineering practice of you know getting you know requirements to build something
00:23:46
Speaker
for an engineering purpose, say a bridge or whatever, compared to what we usually get for software?
From Waterfall to Iterative Development
00:23:54
Speaker
Yeah, well, I think we used to try to build software in a similar fashion, right? That was the the whole waterfall take on software development was let's gather requirements up front and figure out how to build everything, assuming that all those requirements were correct. And we've moved into more of an iterative approach to software development, which I think is is for the better, trying to figure out how to get usable software in front of our our stakeholders and our customers as often as possible. and then
00:24:23
Speaker
you know, responding to any feedback we get there. And I think that works well for software because it is malleable, right? Like, we can make changes. It is virtual, like we've talked about. So there's not as much material waste there. We don't have to throw away material if we were to make a big change. But you can't get the time back. There's still time that is spent engineering and developing that software. You're still going to have to refactor things and change things around. the Yeah. The, I guess the issue that you might introduce a bug, right? Or multiple bugs when you're doing that refactor, which I think is misunderstood a lot, especially by, by stakeholders when they ask for sweeping changes. So those are, those are some of the things I can think of at the top of my head, but Aaron, I know you have a ah background in, what is it? Electrical engineering. So I mean, it was more mechanical. Uh, but yeah, I came up as a, in, uh, automotive automation.
00:25:23
Speaker
systems and tooling. and yeah our Our process was basically we would get requirements from a manufacturer and that we had to be able to produce a certain number of vehicles in a section of the plant. So for instance, we were working on an SUV, and we had to produce so many of the body sides in a certain amount of time. And they gave us all those parameters. It was like, OK, you've got a minute and a half to do all of the processing for this body side.
00:26:01
Speaker
And it has to be able to do this at a certain number of jobs per minute or hour or whatever it was. And then our designers would take that information and they'd kind of get the layout of, OK, this is how many stations we're going to need because we can do this many welds in this amount of time and so on. And they'd basically take it. ah piece of onion skin, which is like tracing paper, and sketch it all out and lay it all out. And they pass that off to a layout guy, which was similar to like our designers. And they would produce an assembly drawing that was all the pieces kind of put together. And then they pass that off to a more junior
00:26:49
Speaker
draftsman that would detail it out. So they'd basically trace and lay out the individual pieces, put the dimensions on it so it could be built. Then that would go to a checker and they would open up a vein and put red all over your drawing and ah hand it back to you and go, okay, fix all those things. And you would iterate over it that way until they finally gave it their blessing. You'd roll it up and ship it off to the cut or to the shop floor to be built. And then They would put it together. Once everything was done, you'd run your full test of the line, usually in like a ah clean facility that it was just that part of the line. And they would have some test parts that they would load in and you'd watch it run and the customer would sign off on it. And then they would tear it all down and ship it to the factory.
00:27:44
Speaker
your assembly plant and in the automotive sense. And then we would do this again over and over again. Did you ever have any issues getting from the design like when you went to go build it, right? Where what you thought was going to work or didn't end up working when you actually got into the building phase?
00:28:05
Speaker
Rarely um because there was a In order to get to the different levels, you had to have a good amount of time in seat of knowing how these systems were put together. And a lot of it was carry over. If you were working on a brand new model, it would be like a first time thing, but a lot of times it was just a new model year. So if you think about the changes from, you know, a 2022 vehicle to a 2024 vehicle,
00:28:40
Speaker
of the same name and brand, there's not a lot of differences. Maybe they added some different curves to the body or something like that, or maybe they gave it a little more cabin space. Whatever marketing decided was going to make the car sell better in 2024. And so a lot of that would be, okay, here's all of our carryover parts that we can reuse. And these are the ones that we just need to adjust for the new body. So there was a bit of like refactoring there and you're dealing with steel. So there was a lot of like grinding and, you know, chopping and things. It's like, okay, we don't need this here anymore. So we're going to chop out this section and we're just going to weld in a new piece here and that kind of thing. um And there are times where.
00:29:26
Speaker
You would get it to the, you'd actually get all of your stuff assembled and then you'd have to debug certain things because they didn't quite fit or the clearances were just slightly off. So you were like hitting into something or just wasn't sitting just right. So you'd have to make some adjustments, but that was mainly done by the guys that were building it. So those wouldn't end up making it back to the drawings because it was already built. So a lot of the defect fixing in in post, we actually didn't see because it's like, well, this needs to move down an inch. So we're just going to yank this plate and weld it down an inch and reattach it and it'll be fine. um So yeah, there was there was some of that that happened. um I actually had the opportunity to do some offline um welding robot programming.
00:30:21
Speaker
and ah One of the things with, so there's eight joints on a robot and you would get what was called a singularity. And what would happen is when it would try to resolve to a new location, it would hit the hard stop on a joint. And then it would just whip itself around to get to the other, to the angle from the other way around. which if you can imagine if you're in a tight space with a lot of different machinery, having a robot just whip a 250 pound weld gun around the room is not exactly a sought after response. So usually when
00:31:08
Speaker
You download the program for the first time, you kind of have like the safety circle around a robot and just have it run through. So you could watch it to see if you had any of these singularities where it was hitting a hard limit and then flipping itself around just so that we wouldn't damage all of the other things or, you know, the. Hundreds of thousands of dollars in, in robot that you're, you're working with. So yeah, there was, there, there were some, some things like that, that were just, uh, you, you go to download and it's just, Oh, that did not work. I got to go back to the drawing board on that one. Literally. That's crazy. That's super interesting. But the, the robots, that sounds dangerous. That's why, that's why there was gates around it. It was like, everybody is outside the reach of the robot. Okay. Hit run. And we all just kind of winced and.
00:32:03
Speaker
And held back, it was like, okay, please, Rod, please, Rod. And you'd see it go in and and you had like this small adjustment spots where it was coming in and doing the fine adjustments to get just right. um And you're like, okay. And then you hold your breath as it pause for the weld. And then as it comes back out, you're like, okay, okay, okay. And then it does the fast motion. You're like, oh, please, please, please. And then singularity happens. You're like, God. Because usually it was in in the motion between point A to point, the like the long traverse, that it would end up hitting the singularity. Because you're that's where the big adjustments were happening.
00:32:48
Speaker
James, do you have any perspective on software engineering versus other engineering disciplines? Well, I mean, it it kind of struck me a little bit as Aaron was talking about it. I mean, you know especially in the you know the automotive industry, you're you're trying to optimize for repeatable processes and and building the exact same thing many times to a very high degree of specification, right? that just does That's just not our world, right? I mean, I don't know. Have you ever built even anything that looks maybe somewhat the same, but I mean, is ah have you ever built the exact same system for multiple customers ever in your career? I have not, no, right? Like it seems like they can be tangentially similar. A lot of times they have similar layers, right? Like we have an API layer, we have a front-end layer, we have an infrastructure behind it generally.
00:33:40
Speaker
But yeah, the business logic is very unique. Yeah, patterns tend to seem to be the same, but the actual problems are always different. right Or there's always that one nuance that that catches you for a week or two that's, oh, well, this is different. So let me, let me pose a question.
Explaining Software Complexities to Non-Techies
00:34:01
Speaker
Cause I feel like the, the people outside of the software engineering industry, they still struggle to understand that because there's something we can do better as an industry, like in terms of explaining this or or helping bring to light, like why it is different and like what the difference is. We need street artists to start painting murals of code.
00:34:24
Speaker
But we, yeah, I mean, it's basically we need, it's one of those things where we need to have an understanding that this isn't just throwing numbers around and typing in a bunch of code and then it just works and that's all we do. there There is an art in a craft to what we do and getting that understanding ah out there as a, as it It is a mixture of right and left brain because you need the creativity to think of new solutions to upcoming problems that haven't been thought of before. For example, the in the last six months to a year, AI has been the big thing. Well, now we need creative solutions for how do we integrate AI into the types of problem sets we've been working in
00:35:22
Speaker
to get to that next level. How you know how how can we use this that in a way that will be beneficial to our customers and promote their systems to the next level? and That's it's all creativity in in artistic form. is it's really thinking outside the box. Which, if you're if you're in a job where you're doing the same type of thing over and over again, you're going to see the same problem over and over again. You just ah adjust some of the parameters of what you're building. And that's what I saw from Inside Engineering. Yeah, oh, OK, it's another car body. OK, I already know how to do this. It's just this, this, this, this, this, build it backwards, bubble blah, blah, blah. Boom, boom, boom, it's done.
00:36:09
Speaker
know it's The numbers in and the components may change a little bit, but the process doesn't change. There's not a lot of creativity on how you do that until you get those those rare edge cases on on being able to um solve that problem. But for us, because technologies continue to change over and over again, we have to be creative about how we can implement those into our solutions for customers because they want the latest and greatest. Yeah, I think I keep coming back to like the difference between pure greenfield development and legacy systems too.
00:36:51
Speaker
i trying to to estimate a greenfield project is a lot, it's a lot easier. You don't have any dependencies. You don't have to try to read all that code. So that's, so I've had success doing that with teams too, being pretty darn accurate within, you know, a week or two, which is about what you would expect in like new construction and stuff too. I mean, let's not pretend that construction doesn't ever go over either, right? Like projects are very late at times, six months to a year. So they're not perfect either in other industries. But I think one of the biggest problems we have is is the legacy aspect of what and the dependencies aspect of what we have to work with. And I think that boils down to the unforeseen, right? And it's why restoration projects are even in construction or with anything have that risk factor of the unforeseen. And it's the same thing with legacy systems. You don't know what's wrong with it until you dig into it.
00:37:49
Speaker
um even exploratory surgery is the same way. you know they They don't know exactly what it is until they get their eyes on it and can see the problem. And I think legacy systems have that buried in a bunch of code to where you don't ah you may not uncover it for six months after you start a project.
00:38:10
Speaker
well do we Do we think we arrived at a place where, you know, you you asked a question, you know, kind of a call to action almost of how how can we do a better job of explaining what it is we we do? The problem, Aaron, I think with, because I take the same approach you do of of like, oh, there's, there's art to it and all of that. But I think it kind of falls on deaf ears because that perception that it's just a bunch of number geeks with, you know, slide rulers and all that stuff that are doing this programming thing. It's almost self-serving. It's like, oh, you're just trying to make yourself sound like something fancy when you're not, right? Like, come on, you're just a geek or a nerd, right? I don't know. I think maybe some of the, there does seem to be more of teaching kids about coding. And so there may be more of an empathy there that people have some familiarity with it. Cause I think it is all, it's very opaque to the majority of the population right now that they just have no
00:39:03
Speaker
concept of what it even is that we we do.
Accessibility of Coding Tools
00:39:06
Speaker
maybe Maybe that's part of it and maybe it'll get better over time as more people get introduced to it. What do you guys think? I think there's some truth to that. I also think it's it's getting more accessible right for people to to do some of the things that they could not do before. If you want to go create a website now, you don't have to have a whole lot of programming like or knowledge. There's so many tools out there that you can just slap some stuff together. What you see is what you get. You have a basic website and lots of people that have done that.
00:39:36
Speaker
And there's also people that have made a living out of using those tools to make websites for other people because they don't even want to get to a place where they're doing that. So I don't know, we'll see if AI ends up making us all obsolete or if if we just continue to get better and better at building tools that allow people without the technical skill sets to solve the problems they want to solve. And I also think we that with the accessibility and making it more accessible, people will stop with the stigma of you have to be a genius in order to be able to do what we do. um You know, I was I was actually talking with a gaming group that I play with, and they want to produce their own mods and stuff. And I was talking about coding and, and they're all just like, Oh, that's so beyond me, you got to be like genius level to do that kind of stuff. I'm like, No, actually, you don't. You know, there's, if you
00:40:33
Speaker
break it down a certain way and you kind of follow a certain amount of steps, it just becomes researching the how. you know The what is is very approachable. If you think about coding in a way of from like a pseudo code kind of manner, it's like, well, I need to do this first. Once I have that, I can do that. Oh, I forgot to do this. So I'm going to put that back up here. And then you just kind of piece it together, kind of like you would a jigsaw puzzle. you know oh I'm going to start with the edges and then I'm going to start filling in the different pictures. and You can approach voting that way and and make it more accessible. um Languages like ah that that are visual programming ones. um There's a few different ones out there where you just have like little code blocks, you just snap them together.
00:41:25
Speaker
And it's usually meant for like elementary level, like coding exercises and things like that for teaching kids how to code. Those things are awesome. I love those things. Well, I'm not less letting any of my family listen to this episode for sure. Cause I have them all fooled to think I am some sports, like some sort of super genius. So I really kind of dig them, you know, that aspect and I don't want them to not think I'm a super genius. and Those of us that are, we recognize our own. but you're right i mean you all know i'm not you guys can see right through it like
00:41:59
Speaker
My family doesn't have anything to do with this industry. You all know I'm not a super genius, of course. All right.
Interview Wrap-Up
00:42:05
Speaker
Well, I think you know we've we've definitely appreciated your time today, Dylan, about but we we do have a little thing we do every now and then. We call it the lightning round. I mean, we really get down into the nitty gritty of things with this and real real questions.
Preferences: Open-Source vs. Commercial APM
00:42:21
Speaker
When it comes to APM tools, are you a fan of using you more open source and kind of wiring everything together your own or or buying off the shelf commercial products? Am I allowed to say it depends for these hot take lightning rounds? Is that an acceptable answer? Do I have to be super concrete about it? I think um i think it does depend, right, for this particular one. Most of the time I'm gonna recommend buying an off the shelf tool and I think it,
00:42:49
Speaker
most Most organizations, it's hard to get them to want to invest in performance monitoring application performance performance monitoring anyway. right When you tell them that they have to stand up an entire team to do it to do it correctly and invest in learning these open source technologies and building out your own dashboards, that's ah that's a pretty tall order and a tall ask. so It's very easy. These application performance monitoring tools have gotten pretty mature. Your Dyna traces, your data dogs, your new relics. Yes, they can be expensive depending on how big your organization is, but I think what you get out of it is well worth it. It's often
00:43:25
Speaker
plug and play, right? And you get things like distributed tracing out of the box, get alerting out of the box. They'll do analysis and and find discrepancies if your latency looks different than your baseline. like There's a lot of really cool functionality that it would take you quite a long time to build using open source tools. And for those playing along at home, APM stands for Application Performance Monitoring.
Quick-Fire Tech Preferences
00:43:51
Speaker
All right. So Kubernetes or like ACS? So again, it depends. i'm I'm going to lean towards the ecosystem on this one. So I really liked the ecosystem around Kubernetes and what you get there with the open source community, Helm charts, you can just plug stuff in, whatever you whatever you want to deploy, someone else has probably already built something out for that, right? yeah ECS is definitely simpler, but you're also tied into that.
00:44:22
Speaker
Amazon ecosystem, depending on how you feel about that. So I would, I would lean Kubernetes most of the time. Unless you just really don't have the resources or have no familiarity with, with Kubernetes, but it's become not as much of a concern management of large Kubernetes clusters with ah the managed offerings you get from the large cloud providers. Now they take, they do a lot of the heavy lifting for you. Uh, Java or dot.net. Oh yeah. softball. Again, I'm going to fall back on the ecosystem part. So I'm going to lean towards Java, I like dotnet a lot. But for me, like programming languages, really aren't that important. I feel like learning the programming language is the easy part. The hard part is often the ecosystem around the language, right? And, and what you get from the community. And dotnet has some decent support there. But a lot of it
00:45:15
Speaker
You're also dependent on Microsoft for Java, having more of the, I think, of ah an open source community around it. There's just a ah lot more available to you. And I think it's more robust. So I'm going to take Java.
Star Wars vs. Star Trek Preference
00:45:28
Speaker
Star Wars or Star Trek? Oh, that's easy. Star Wars. I don't think I ever really watched Star Trek. I think I'm, I think I might be too young for that. Well, they had multiple generations. I mean, they, they've had like, 10 generations of Star Trek. They're trying to reignite it every few years. Yeah. How's that going for him? Not great. All right.
Game of Thrones vs. The Walking Dead
00:45:51
Speaker
Walking Dead or Game of Thrones? Oh, um Game of Thrones for sure. Game of Thrones production quality is just so much better, right? Walking Dead I wanted to like a lot. And like there's some good stuff in there. But the production quality is just not nearly as good. The acting is not as good. it's just They're not even in the same league, in my opinion. know
00:46:12
Speaker
I will have to say that the Walking Dead, like one of the early episodes where, you know, Rick's waking up in the hospital and realizing the world has gone to hell around him. When they redid that, they usually do it around Halloween or they would do it around Halloween where they'd play the whole thing in black and white. Watching that particular episode in black and white was really cool. So I do like it, but I am more of a Game of Thrones
Episode Conclusion
00:46:33
Speaker
fan. All right. And let's end on the really important, um, Coke or Pepsi? Definitely Coke. I don't think I've. I don't drink a lot of pop in general, but, uh, the only thing I would ever drink from Pepsi might be Mountain Dew. So definitely Coke. Yeah. Yeah. I mean, this is America. So yeah. how you coax the right Get all hopped up on Mountain Dew. All right. Well, I think that's it. Uh, Aaron.
00:47:01
Speaker
So that's all we have time for today. Thank you to our guest Dylan, our production staff, and my lovely co-host James Carmen. This has been the forward slash where we lean into the future of IT. Thank you and stay tuned for the next episode.