Software Development Challenges and How To Navigate Them

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are continuing season 21. For those of you that are podcast listeners, the rest of you, thank you for hanging out with us. As you're out on the YouTube channel, we're continuing to talk through how to be better developers. And this is really our focus is our focus is our focus now. We have drifted a little bit. If you go way back, I think developer is now seven or eight years old. We've been around since 2016, 2017. I forget when we originally launched, but we have drifted. We sort of started with a very tight focus, but then as we've added content and we just sort of put stuff out there, we've gotten very broad. And one of the things we want to do is bring it back down. Our avatars was not, it was not an avatar. It was like a Coliseum of avatars that we were servicing. And so now we're trying to bring stuff down. Avatar just for those you don't know, it's your ideal customer. It's like, this is who you want to talk to. It is defining your niche down to one person and knowing that person as far as like, how old are they? What do they like to do? What are their hobbies? What is their day job like? What is their commute like? Those kinds of things. And we're not going to get too deep into that piece, but if you go Google, how do I define my avatar or how do I create my business avatar or my ideal customer? Those things, you'll find lots of recommendations around that. That's going to be some of what we discuss as we're building the developer brand here. Today, we are going to talk a little more technology. We're going to talk, or I guess more problem solving. We have in the past, we have discussed some of our current challenges and some of the customers we've run into. And this episode, I want to talk about something that we actually find fairly often. It is a customer that has gotten themselves into a bind of some sort for a variety of reasons we'll talk about. They've gotten themselves into, sort of like got themselves in a bind. They're in a little bit of a corner and they're trying to figure out a way out. And how do we as a consultant, as a technologist, as a problem solver, help them out of that? How do we get them out of that corner and not only get them out of that, but I think one of the best things we can do is set them up so they don't end up back there, so that they are taking some steps to avoid getting back into that situation. There's a lot of different ways that you can be sort of pigeonholed and things like that. There's vendor lock-in. There is essentially what I call technology sprawl, where you just have got, you've just grown and grown and grown and grown and you've just got 18,000 solutions of technology. So you may have, like we've been in places, there's three or four people in the shop and there are 20 different technologies that they're trying to maintain, which is just way, way too much. It becomes more of a headache of switching gears than it is actually solving anything. I think I'll start with, before I get into my specific story that I did want to talk about that we did, I think I'll start with Mike. What do you see as the most common, maybe one or three issues that you've run into as far as these businesses gotten themselves into? Because I know you've dealt with a lot of small businesses where they've sort of, they just haven't done what we would say the ideal solution is. And so what are maybe some of the common pitfalls you've seen? So interestingly enough, so some of the ones that are one of the biggest problems I see a lot of companies doing, especially non-technical companies that want to get into tech, where they want like a mobile app or they want like a desktop application or they want some type of technology solution to their problem. What a lot of them do is they go out and they do not do a lot of research. They find the first product online that kind of meets their needs. They buy it, they implement it. And now here we are three, four years down the road and they have to hire someone to come in and maintain this because no one supports it anymore. The companies either out of business, they don't do proper updates or the software never did what they wanted and they have so much customization that it just doesn't work anymore. It's like a hot mess. That's one of the number one problems I have. Number two is it's a startup or they're in that startup mentality and they want to do things cheap. So they don't want to spend money and instead they go out and find all these open source possible solutions for their problem, mishmash them together without much thought and quickly throw something out there. The problem with those instances is they usually are hard to maintain or they do not scale. So once the company starts to grow, you run into a situation of oops, this doesn't work. We have to either go back and rewrite it or throw a lot of money and development time into this to actually make it work the way we expect it to work. And probably the third thing, companies really have no freaking clue what they're doing and it's a hot mess from the beginning. They hire people to do what they think they want and you typically end up in that swing set scenario for those of you that probably might not have seen this. Google swings, what is it? Swing set problem or roller coaster design online. You'll see a little cartoon which starts with a tree swing and ends with the customer really wanting a tire swing. And that is kind of the third situation I find myself in where the company either pitches one thing and delivers something else or they totally misread what the customer wants and they build something that doesn't meet the problem. It's something that's a total waste of time. Yeah, and I think that is probably the biggest problem regardless is that communication thing that you get from that tree swing. And I think there's also the roller coaster example of that that are totally, it shows you the difference, the different things that are communicated and how vision being translated into reality can be not the same. They can be very, very different. The one I want to talk about, the example I've got is I think probably that second one a little bit. It's a little bit of a budget kind of thing, but this is also something I've seen quite a bit, particularly for startups and small companies. This customer contacted me and the initial issue was or initial request was they had a system. They've been using it for a couple of years. It was critical. It was time entry. It was things like that people get paid based off of this and they invoiced off of it. I mean, not directly, but it was like this was core data for their business. And it had been built by, I think he went to church with a guy or was like a Cub Scout leader with him or something like that. And so it's somebody he knew that was a developer and they're like, hey, I can go do this. And so it was a side hustle developer. The guy that was doing it was just like, hey, I can write some code on the side. I can give you a good deal. We'll put something together. And so he went with what he knew, which happened to be it was MySQL was on the back end. I want to make sure it may have been SQL Server now. I'm trying to remember what the back end was originally. It may have been actually SQL Server on the back end. But then it was also, it was classic ASP on the front end, not ASP.net, classic ASP. It was running on just a Windows Server with just IIS. And it was just basically like, there's your code. And the way that was his version control was, hey, we back up the server every so often. So there was no version control. There was just something we probably see quite a bit where the versions where it would be like a page and they would have a page with another number on it, or it would have a date on it, or it'd be like page underscore testing new thing, stuff like that where it's like you look at the folder of files and you're like, oh, wow, you've just been, this is just a developer machine. And they're just basically developing on the server, which not usually a good approach. That usually tends to be something that causes some issues. So coming into that, I guess I'll put you on the hot seat a little bit. So giving that little thing, what would be your, maybe like, how do you approach that? Or maybe what would be your first recommendation to a customer when you walk into that kind of situation? Well, the first part, I would try not to laugh about the lack of version control, but because from a developer standpoint, especially like as a contractor or just an employee, walking into a situation like that is never ideal. We don't want to see software in such a state that it's not maintainable. So one of the first questions would be is what from, so I'm going to take this a little bit from my company's perspective, from like QA perspective. So looking at from a software with QA in mind, the first question I would be is, okay, who is the customer you're serving? What is this application serving? What is the problem you're trying to solve? And from there, I would basically define the user story, define the use case that you're trying to solve with this software. Then I would go to the end product and say, okay, what is it that you are actually providing? Are you meeting this use case? Are you actually delivering something that meets what your expectations are at the beginning? And then if you're not, then you slowly peel back the onion and walk through the different stages and find out, okay, what do you have implemented? What kind of technologies do you have? What's your stack? And from there, you look at it is, well, that would be the first thing. The second thing would be, what is your budget? Because if they come at me and say, I have no budget, I have no money, this has to be start mentality, this has to be open source. So the first thing I would look at is, are you using the right technologies? You mentioned SQL Server. Well, my first comment there would be, why are you paying for licenses if you can't afford it? MySQL does pretty much everything you need. Switch over to something that's more open source. MySQL, Postgres, something like that. Frontend. First of all, ASP core or basic ASP really has not been used in a while. So that would be another red flag because finding developers to develop in that is going to be very expensive. So the next thing you want to do is, okay, if you want to keep it as a scripting language, JavaScript's pretty much the de facto, maybe go with JavaScript, maybe PHP, maybe even Python, depending upon what it is that you need to push out the door. And then kind of walk through the technologies there. The other thing I would definitely push would be get version control in ASAP. And then if, since they don't have version control, chances are they probably have little or no QA in process at all. And I would probably at least instantiate some simple QA scripts out there to at least test the core functionality. Make sure that what the product is supposed to do is at least doing that. You may not have negative test cases to test if it breaks, but at least test the basics to make sure it's going out the door correctly since you don't have version control. Because then you would at least know that what's going out works. And then you can apply version control over that to say, okay, this is a stable version. Because if it doesn't work, you're not stable. So you're going to know right away, okay, this is basically going back to an alpha version. Yeah. And that's, it's interesting because that's, you know, even from a QA perspective, if you flip that more to just a pure development perspective, it's really the same thing. I think the key there is you start off, you don't come in and just like start ripping out code and changing stuff. There's some key things you have to do is like get the context of what's going on. There's make sure that you're clear on that. And it's the first thing really is sort of like the why. Why does this thing exist? Who is it serving? How, what does successful serving your customer look like? Which sometimes, and this goes back to our couple of earlier points, sometimes a business hasn't really thought through their processes completely. And they can be many years into business and still have gray areas within their processes or things that they don't really understand because they've spread that out across a couple of different employees or departments. And there's not really somebody that knows how it all plugs together. It's sort of like a bunch of black boxes that are just tossing stuff from box to box, as opposed to somebody being able to trace that all the way through. I think that's one of the key things. And that was one of the things I talked to them about. I said, okay, you've got this big sprawling thing. It had, oh, like, I want to say it had like two dozen, maybe three dozen menu items. And basically you'd think of each of those was a page and some little like process to it. And we talked about it and talked a little bit about the budgets. Like, okay, well, what do you want to do? And I knew coming into it that he had a limited budget. It was one of these things like this needs to be fixed in, yeah, I think it was like 10 to 20 hours of work, something like that. And he had some key bugs, like the database every so often was just rewriting, like it would do a mass update of the employee table and like all their times would get set to whoever the last one was that saved it, which was interesting enough. Never could figure out how to reproduce it. It would happen periodically, had logs, everything. It was some feature of that structure that was part of why we went on to the next project, which was basically we saw a couple things there, did a couple things to get some backups going and to basically just develop, just like define a simple deployment process of, okay, let's take this code. We're going to put it out into GitHub, I think is where I ended up putting it, or some Git repository. And that's where we're going to start doing our builds from. Instead of putting everything on that server and just writing code there, we're going to have access. So if there's a developer comes in, they can always pull the code down and they can push it back up. And then we had just a little, it was just a little simple Ant script that was essentially like just copy from point A to point B once you've downloaded everything. But then from there, it was very quickly, he's like, well, hey, well, what's really critical? Because this is something that's been built over a couple of years. And now you want to essentially, the recommendation was scrap it and start all over, but that may not be valid. But it actually turned out to be because he said, well, you know what, I really only need this one function, which was funny because it was actually like 10 functions. But he was really like, I just need employees to be able to enter their time. And I'm like, great, that's like one page and we can do that. The conversation continued and it was like, oh, well, there's these lookup values and there's these computation values. And so it's like that one page turned into one or two pages, well, it was one page for the user. There's like 10 admin pages behind it for the configuration data. And I think that's one of the things that I always want to recommend is like ask that extra question as far as like, and then what, or is that all, or how about what happens in this case? Because when you do that, then you can get those details. And then as you're stepping in like this, I think this is a key point that you brought up as well, something we did is like try the best you can to leave it in better shape than you found it. It's one of those, it's like, okay, they don't have anything. So at the very least, you could get them some scripts that would be, I can, regardless of your skill level, you could easily build a couple of scripts that are, if you run this, we'll copy the code from point A to point B. So there's actually a production folder at least and a development folder that's separate. And then also version control is so easy these days. And it's so much easier to share code out, to track changes, to not have 15 different copies of a file in there. There's just so many benefits to that. And it's so accessible. If you don't have a GitHub account, pause right here, stop, go sign up. It takes like no time. And people start, it should be on your resume. A lot of places now will request, like, can I get your GitHub ID or link to see what your, even from, if you do a lot of private stuff, like what's your general activity and things like that. It's almost like having a LinkedIn page for developers is having that GitHub thing. And so that's what we did is it was, it is, it's like you go to the Y, you figure out what the focus is. And this is something I think from a consulting point of view and something we'll probably talk about in our next session here, is how, it's also very indicative of the assessment, audit type products that we're trying to build. Because that's initially what it was. It was like, he was basically like, tell me why this is broken. I need this fixed. Can you do a couple of things to fix this piece? Because I know I've got this huge thing, but I really want this one piece. I just need it to work. And so we did, we extracted it. And I told him, I said, actually, what I could do is you can leave all that other stuff there. We built, I said, you know what, I can spin up a little Python Django app that's basically just going to point to the same database, pull the data. I've got like one or two forms. And now it's like, we're going to rewrite that page. We're going to just pull it. Like none of the code that does that entry and that validation is there anymore. We're going to rewrite the whole thing. We're going to make sure that it's done in a manner that is much easier to maintain. It's a current language. And worst case, if I had walked away, it'd be like, at least this key problem that he needs solved is in a modern language. It's something that there's a lot of developers out there. And it was set up in a case, in a sense, in a way that somebody could come in real quickly and be like, okay, here it is. Here's the documentation. Here's how you run it. Here's how you get it. Here's how you launch it. And you could swap developers in and out fairly easily. So thoughts on that, because I know we had a good conversation before. Sore Thorne, your two cents at a couple of those things. So I don't want to go too far down the rabbit hole on that one, because that's a whole discussion in and of itself, getting into the design process and building it. Because one of the things, in your case, you had to get this fixed for them quickly. They were in a bad state. That's one of the things we'll probably discuss at a later point where there's the, right now, there's what can you do a little bit better and then the best way to do things. But in this particular situation, the only thing I would like to add is by doing what you did, you also set it up to a point where you could get them to a point of continuous integration, where they could make a change, copy the development folder to prod to roll it out the door. So you actually started building some processes for them that it seemed that they didn't have at all. And that's another thing that a lot of companies miss when they build software. They don't think about the processes of developing the code, testing the code, deploying the code, and maintaining the code. That whole software development lifecycle kind of gets lost. If you think about the agile environment, if a company just says, oh, well, we're agile, we're just going to write code and deploy code without thinking through the process, they get into trouble, right? Yeah. And I think that's a, that is actually a very, that's its own long conversation, probably a religious conversation for some people is agile and how it, what it does to the software development lifecycle. And technically, if you're paying attention and doing it right, agile does not change the software development lifecycle. You're still doing it. You're doing it differently. It's not like waterfall. It's not as necessarily maybe distinct, although I think there's still those distinct tasks still exist if you're doing it right. Like if you're, if you're doing agile and you're not doing requirements gathering or design, you're doing it wrong. If you're not doing testing, you're doing it wrong. If you're not deploying it, what's going to be obvious, you're not doing it wrong because nobody's going to be able to use it. It's like, hey, I think I got all the way through. Why, what, what's wrong with this project? Oh, well, it's because you didn't get to the deployment phase. And so nobody is actually able to access it, which funny enough is, you know, that's one of the things that agile's like, you know, drawing points is we are going to deploy on a regular basis. So you're going to have a useful deployment release at the end of effectively, hopefully each sprint is that you've got something that you can work with. And I think that's, that's something that I want to sort of, as we're getting to this one is, there is a, as you said, it's sort of like that rabbit hole. And I think we, as developers often run into the problem that we, especially as we get into, you know, once we've gotten past our first few years and now we, we sort of, we've done this before, we've got some ideas, we sort of are starting to settle into our ways of developing software that we feel we have like sort of our ideal and that we don't move off of that. It's like, well, this is how it has to be done. And that's not the case. I mean, ideally, yes, if we had unlimited funds and time, then yeah, there's all these things that we want to do. But the challenge, and I think what makes a successful consultant is being able to come in and meet the customer where they're at. Instead of saying you need this enterprise grade solution, it's saying, okay, you have a limited budget, you have a limited time, you have a couple of things that are on fire and need to be put out. And so it's being able to come in and do that triage and do it in a way that is not just like slapping a bandaid on something, but instead saying, okay, yes, we have to slap a bandaid, we have to stop the bleeding, but let's try to do it in a way that is setting ourselves up for success at some point. Now, sometimes you're, let me just, you're, it's like, you only have time to slap a bandaid on it and move on. It's like, you can put out the one fire, but you don't have time to do anything to like address the other fires. But that's usually not the case. Usually if you take a second and instead of just panicking and going like, oh, we're just going to fix this bug, which is probably how they got into that situation, you think about a little bit, you research a little bit. Like you said, as you like explore that a little bit more, like, okay, what, what really are you trying to do? What really is going on here? Because sometimes then you're going to realize that now you're not just hitting your, you're not just dealing with the effect. You can actually go find the cause and either directly address that, or at least put that on their roadmap to say, hey, this is why you're running into it. Which would be like a perfect example would be people that don't do QA. They're like, hey, if you keep having the same bug come up over and over again, then maybe you should try like some testing of some sort, maybe like a little regression test so that before it goes out to production, you know that you broke it again. Or version control. So you know that, oh yeah, we changed this section of code. So we need to make sure that it actually works as opposed to throwing all your code out there and go up. It's broken because it's broken. It's not a very useful way to debug stuff. Thoughts? Well, and you know, as developers and you mentioned this, and this is something I think we, you're probably going to hear us both say this a lot. Make sure you always leave the code in a better state than you started with. Don't half-ass it. Make sure you do a good enough, you know, make sure you do the job well enough. If it's just putting out a fire, if it's just fixing a little bug, make sure the code is clean and concise and it's in a good place that you're not taking like 20 year old technology and still throwing in 20 year old technology. If you can do it with newer technology and do it right, do it right. Yeah, I think that that leave it better than you. You found it is probably one of the most important things to do is it's like that's what, particularly if you're going into a consulting role, if you can do that, if you can come in and regardless of where you're at, you know, wherever you enter a project that you enter it and your work is an improvement on what was there, at least as good as they had, but usually if you can find a way to improve it, which is, you know, better documentation, cleaner code, better performing stuff, whatever it is, then that's going to help you professionally because then they're going to say, hey, you know, Michael came in and he did this work and it was so much better than the other stuff that we had. It's also going to be more likely they're going to bring you back and say, hey, you did a great job on this. We want you to work on that. And that's sort of the moral of the story. The happy ending we'll call of the project that I went into is it was originally, I think I said like, it's like a five to 10 hour project. At this point, that was a, I think now almost a year and a half ago that I first kind of, you know, we first started working with them and it has turned into probably 250, 300 hours, something like that, that we've gone into it. We've rewritten the entire system. We've added pieces to it. It is, it's stable. It actually, from the customer point of view, it is something that's probably, I don't know, I bet it saved them easily, you know, tens of thousands, I think probably, you know, hundreds of thousands of dollars because they were going to take that solution and replace it with something that was going to be much more expensive. It was going to be much higher end. It was going to be like a Salesforce or something along those lines. But now they've realized that they can take that customized piece. We cleaned it up. We've really refined it over the last year and helped them define a couple of their processes, but also added enough features that they're like, nah, I don't think we really need that now. We've got what we need. And there are a few integrations that they wouldn't, you know, they wouldn't mind having. And they've actually, a couple they would love to have that we can't because the provider, the vendor doesn't allow integration. But this is like a win-win-win kind of thing is that we have come in, we showed them and the customer even said that was part of it. He's like, hey, I want to see if you can solve this little problem. And if you can solve this little problem and I trust you, then we're going to work on bigger problems. And so we've built that trust. We've built that relationship. And now it's turned into a steady stream of work for us, but also a steady stream of improvements for him and his organization. And it's allowed us to have something that we've built. And we are, it really is at a point that we can walk away from it and we can just be like, here you go. Here's all your pieces. We've got a little bit of documentation left, a little bit of handoff to their technology people. But it's really to that point where it's like, you guys can maintain it from here on if you want. If you want us to add features, we can do that. And so it really is. It's just like you, it's one of those things, it's like good work is its own reward. So I'll give you the last two cents before we wrap this one up. Yeah. One of the things, and I like that you said that is not only leave the code in a good place, but make sure you leave with the customer in a good place. Make sure you have a good handoff, make sure that you communicate what you did. So if the customer does have to go out and find someone else to do the work, they can hand it off to someone else cleanly so that they're not in a situation where, oh, you know, this is another hot mess. I need to come in and have this rewritten. You know, if you're leaving it in a good place, you should also leave the handoff in a good place. And like you said, Rob, you know, some additional documentation might be needed or maybe even just a quick little summary write-up of what the work that was done and where it is and maybe a project structure. Excellent. Well said. And we've sort of run out of our time for this episode. So I want to thank you guys for listening. As always, shoot us an email at info at development.com. If you have any questions, comments, you can leave notes, things up, comments on the site if you're on YouTube, or you can also see, leave them out on Develop-a-Nor or wherever, if they allow comments, wherever you are listening to podcasts, feel free to do so. Always looking for more information. And we're just here to serve you to help you guys become better developers. That being said, we're going to wrap this one up. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.