Solving Problems in Software Projects | Building Better Developers with AI

Welcome to Building Better Developers, the Developer Noir 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 our season of Developing World, Building Better Developers with AI. Yes, we're going to use AI this time because everybody else is using it. No, we're not going to send like killer Terminator robots to your house, but we are going to terminate all of your fears about developing, becoming a better developer. This episode, we're actually going to throw out to AI. What would be a good way to talk about solving problems without solving the problem? We're going to see what happens. But first, I want to introduce myself. I am Rob Brodhead, one of the founders of Developing Noir, also a founder of RB Consulting, where we work with our customers to understand their business, help craft a special recipe that's just for them, their business, how they specially work. This could be you. What is your specific problem? I know each industry has got its family of problems, but each business has got its own little niche, its own way of approaching it. And that is required in order to find the best solution of the best way to use your technology, whether that is through simplification, integration, automation or innovation. How do you take that big, expensive investment that you have and turn it into something that is a real good return on investment? That's what we do. We sit down with you and help you figure out the best way forward, use a technology assessment, and then move into a roadmap so that you can plot out your course and execute on that. Good thing, bad thing. Good thing, bad thing. Boy, this has been a week of that. So good thing, finally got through more or less. We close on a house that has been in the works for a while tomorrow. So we've gotten through lots of stuff. There's been all kinds of things that have gone on. This housing shift journey kind of thing started months ago. We're not moving, moving into this right away. So we are not done yet. We're going to continue to move on and I'm sure have some struggles, but at least we're getting closer. So I'm going to say that's a good thing. Bad thing is, I hate to say it, but it's finally starting to get hot out. It was like, it's June and we've had great weather and it's finally starting to get hot enough that I'm like, ah, it's too hot. It's like I have to turn the air on and stuff like that. So that's the bad thing. A good thing for you guys is now you get to listen to Michael while he introduces himself. Hey everyone. My name is Michael Mollosch. I'm one of the co-founders of developer building better developers. I'm also the founder of Invision QA where we are a software company that essentially helps customers, helps businesses with their software problems. It can be anything from custom software. It can be from store-bought software. If you are struggling with technology and your business to make your customers happy or essentially just getting through the day with your technology working so you can get the work done, give us a call. We will walk through the trenches with you to understand all the problems and all your processes within your company and that we will help to devise a process and a program to get you to the end of your journey to improve all these caveats, all these problems that you're having. So either you will have a better customer experience with your application or you're just going to have a better experience going into work. You'll be happy to work in your business, not hate working in your business and just, you know, hey, let someone else do it. Good thing, good thing this time. So bad things, you know, weather's been bad, all that crap all the last few episodes. We got our lawnmower back that I broke a couple of weeks ago. So weather's been warmer, as Rob mentioned, but it's been comfortable enough that we've actually been able to sit outside, enjoy the weather. And my wife got the little 10 foot pull up and we were able to jump in that. It was actually not too cold. We were able to get in that and enjoy that. And we were actually able to get out to the river house and actually had decent weather for a day, but we actually had decent weather out at the river. So we are almost past this rainy season and it is sunny skies for a while, maybe warm, it's still sunny. Is it cold, rainy, drabby or snow? Yeah, if you start hitting snow in June, we're in trouble. This episode we are diving into, we're asking AI as we are in each of these, going back two seasons back, we're taking the topic and we're asking AI about it. So this time the topic is solving problems without solving the problem. Now as always, AI loves us. It thinks we're really smart and nice. So it says it's a clever and thought provoking topic. Let's see how well AI was clever and thought provoking. So first recommendation, the illusion of progress. Just writing code doesn't mean you're solving the real problem. Devs often solve symptoms, not root causes. Entrepreneurs sometimes launch features that no one needs. Message progress isn't about activity, it's about accuracy. Oh my gosh, this is another one that just like bang, writing the gist. This is something we talk about way too often about being productive versus being busy. We talk about the why. This goes back to what we talked about last time. The why, why are you doing this? Features that nobody cares about. Bells and whistles. It's about doing stuff, adding features, building functionality that helps people solve the problem or problems better, faster. Don't make them stick around. If you're in the marketing world and you want people to stick on your site and stuff like that, that's cool, make it fun. But the problem you're solving there is that people want to go away from your site. So solve that problem properly. Don't find ways to stumble across that. I love that one so much. I'm not going to talk the whole episode, but I am going to go ahead and toss it over to you because I know you have things to say as well. Yeah, from the marketing side, it's kind of like handing out those $10 Starbucks cards to people to go look at your site, not fixing the problem on your site. It's like, here, we'll pay you to come look at our site, not actually fix the site to make you stay or want to come to us. Oh my God. I mean, that's probably the best example. It's like, are you busy or are you getting stuff done? Are you solving the problem at hand? We've talked about this a lot. We've actually talked about this on some projects we've been on. It gets back to what is the MVP? What is the end goal? What is it that the customer needs to complete the project? Now, if you get the project done and you have time left, that's when you add all the bells and whistles. Do not add the bells and whistles at the beginning. Get the MVP done, then work on the extra features. That is well, before we go on, I have to say that is so hard. We get into the heady times of starting a new project, and we have all these visions and all this stuff we can do. And it seems like the world is our oyster and we can do whatever we want. And the reality smacks us down and says, no, you don't have that much time. You don't have that kind of resources and all the other things that are the constraints that can slow us down. So just find a way to like it's sort of like balancing out that roller coaster of all the excitement and we've got all this energy and then you get towards the end and it's like, I just want this project done. It's a death march and stuff like that. Finding ways to balance that out. Actually, that is part of what I think Agile does, the Scrum approach in particular. But I don't want to get too far into that. So next one. I'll touch on that briefly, though, because with Agile, though, the cool part with Agile is with this roller coaster Rob's talking about, you may have that like high energy at the beginning. It's like, oh, we got all these ideas. You get to a certain point, though, when you're doing the retrospective, throw things out like, hey, did we complete enough of this? Is there something we still need to add? Because maybe one of those fun features can be added now. Well we're still not at the MVP, but because we're in that moment, is it something that can be done now for less time and money versus later? Yeah, there's always that looking for opportunities, finding an opportunity to sneak something in. And it goes back to the idea of having like a backlog, we'll call it, because that's what they do in sprints, of ideas and features that especially if it's not a big one, throw those things on the backlog. And then if you've got a like a lull or you get a little bonus time or something like that, then go ahead and implement that into it. Diagnosing the wrong problem. There's a quote from Einstein, of all people. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem. Devs often fix what's broken on the surface, not what's causing the break. Encourage asking what problem we're actually solving for whom, why now? This is a pet peeve I have with testers and QA and users at times when it's like, this is broke. This doesn't work. Like, OK, you've told me absolutely nothing. Give me something I can work with. The best is when somebody will sit there and there are a lot of tools to do this. So sit there, they will walk through and say, here's what I did. Here's where I got to. This is what I expected. This is what I saw. That gives us a perfect idea of this is what they expected. This is what this should do. And it's doing something different. And that's the key. And it's not just the it's doing something different. This goes back to what we've talked about. Coders are going to just say, OK, I'm just going to make it do something different. All right. It's like, for example, if your logic doesn't you know, when you enter these three values in and your logic doesn't give you the right answer, you just hard code it to say when those three values come in, output the answer that you know it's supposed to be doesn't really help. It's sort of like showing your work when you were in school. It's great that you can come up with an answer, but it's also not necessarily going to be consistent enough. So figure out what you're actually what is the actual problem and go solve that so you're not constantly having to play whack-a-mole, changing all of the things to address the symptoms and not the actual problem. Thoughts on that one? Yeah, so that's so there is a book we went to a global leadership conference a couple of years ago. And I forget the guy. I found the book. Yeah, Dan Heath was talking at the GLS and was talking about upstream solving problems before they happen. And that is one of the biggest keys to being a developer, not a coder. It is not just putting out the fire, but understanding what is causing the fire. What is the overlaying problem that needs to be fixed to fix the things that are happening downstream? And that whole idea, once you get into that mind shift where it's like you start asking yourself, well, what is the underlying cause? Why are we seeing all these problems? Once you start addressing, OK, not fixing the problems, but where is this coming from? Is this a systemic problem with the software itself or is this a systemic problem with the foundation or the overall process of how we built the application? Is there something in the overall logic or code that fundamentally is wrong that is causing everything else downstream? If we go fix this one thing, we suddenly free up 40 hours of bug fixes because the problem is fixed, not fixing the symptoms. Yeah, and that's again, that's one of the areas that I think is why software projects can really have an appearance of being worse than they are, because sometimes it's actually a very small bug. It's a simple fix. Because it doesn't actually get addressed, there's like these band-aids. The band-aids keep falling off and now it looks like it's a complete train wreck, but it's really not that bad. So it will behoove you. It will help you immensely. Spend that little bit extra time, diagnose the problem and try to fix it the first time because I guarantee you, all of my customers I've dealt with over the years, there is I don't think a single one that says I would rather have it fixed right away than to say, you know what, give it the right amount of time, think through it, verify it and move forward. It is way too frustrating for all of us when we try to blow through a solution and then end up having to come back and correct the solution basically. This goes right in to the next one, which is band-aid fixes versus systemic solutions, which is an example of like increasing timeouts instead of fixing latency issues, adding more instead of addressing poor onboarding. Entrepreneurs often throw features at churn when the root problem is unmet expectations. I don't want to get too far into this one because boy, this could go for days, but I will mention that this was specifically a project that went off the rails very long ago. I've talked about it before and the whole idea was that the guy that was running the project, basically they were running out of money. They didn't have the funding to finish it. So he figured out what he needed to do is just get more money. And so what he did is he said, well, there's all these features we're going to add. And he thought it's like, well, we'll just add all these features. It'll be another bucket of money, a bag of money, and then we're going to be fine. Well, what ended up happening is there are all these features and now there's all this other stuff and they took time as well because they didn't really think through it. They took more time than he budgeted for. And now he's in a deeper hole than he was beforehand. So look for the systemic side. This is again, the developer side of it versus the coder side of it. This is a fun one. Lack of context equals misguided solutions. Without understanding the user journey, business model or tech limitations, devs can over engineer or under deliver. Real problem solving requires full stack awareness, not just code. I cannot preach enough on the, this is why we ask the questions. This is why we sit down and we say, okay, well, what about the requirement? What about this situation? How about that? Tell me more about it. The more you can get a conversation out of your customer about what they're doing, what they need, the more you're going to have all kinds of little hidden Easter eggs that come out and go like, oh yeah, there's this thing that we do occasionally or oh yeah, there's this report that we need or oh yeah, there's this requirement that we have that I forgot about that, you know, or they won't even think about it. They'll just be like, oh, well, we do ABC and D and you're like, whoa, whoa, whoa, whoa. I never heard about this C thing before. Go back to that C between B and D and let's explore that. Spend some time really getting to know the problem and the users and what is it? You know, what are you really solving? Not just like, what's the problem, but like, how was that being? So what actually becomes a good solution? Thoughts on that? And it looks like you have plenty. Oh yeah. Uh, so the downside to this, if you don't take the time to listen, if you take the time to ask these questions, but you don't take the time to listen to the customer. I've done this almost any business person has done this. It's like, Oh, I understand what you're saying. Here's how I will solve it. No, sit down, talk through the problem, make the customer do the talking, avoid yes or no questions, encourage more exploration into what it is you're discussing. As Rob said, you could get into a situation where they talk about A, B and C and you've never even heard of C. Well, C could be the critical linchpin to hold the whole thing together. If you miss that, you could get to the very end and find out that you do not have an MVP. You don't even have a product that the customer can use because you missed a core piece of the application. So I've heard this in many business things. I've learned this through experience. Sit down, encourage the customer to talk through the problems, prompt them when needed, and then shut up. The best part of that, actually the best part is in shut up because I think what we need is don't, don't start solving the problem before you've heard the whole problem more importantly, do not ask. Don't ask binary questions. Don't say something that's a yes or no. I have gotten so many times that I've tried to get it to that. Where it's like, just tell me, can this ever occur or can you ensure, guarantee that this situation never happens? I don't know how many times I've had a customer say, yes, that situation will never, ever, ever occur in our business. And then three weeks later, they're like, you got to cover this. This happens all the time. That stuff just drives me nuts. And that's why I've gotten away from it. I'm just like, tell me how your work, your, your stuff goes. Tell me about some of these processes. Let's talk about some of your customers because then I'll start getting real answers and not just the like, okay, I'm going to answer this question for them. Moving on the build trap, building a product or feature doesn't mean it's solving a problem, encourage hypothesis driven development, MVPs that test assumptions, saying no, or not yet to features requests that don't align with goals. This is really an interesting one because we actually tend to fall on the other side of this a little bit more. We've talked more about the idea of where you're never get across the finish line because you're trying to perfect it. You're trying to add like this little feature, this little tweak, or what about this and what about that? This is more of the, we'll ship it and consider it done. And then at least that we've got customers, which you don't want customers when you ship them crap, because then they're just going to wear you out. So this is just because we have a feature or we have the product. Doesn't mean it's actually doing anything useful. So this goes back to really context and things like that. It's like, are you solving the right problem? Are you solving in a way that's actually useful to your users or is it just take them too long, is it too annoying and two other stuff for them to actually make use of it thoughts on that one? So I'm going to just throw a small thought out on this one. We see this all the time. If you are dealing with games as a service, like Diablo path of exile, the game software gets released. It's like, Hey, it's dumb. But then you have these seasons or these things that go on over time. And the game from today versus six months from now, it's a totally different game. You basically have been sold on, Hey, we think the software is good enough to sell it to you, but we're still going to work on getting it to the end product at some point, you know, not calling out a Microsoft who uses its developer, its users to be their testers, because let's face it anytime a Microsoft operating system comes out, it's really not done or stable six to nine months till after it's released, there are so many bug patches next, you know, there's just problems with software be careful with that. Make sure that what you are delivering is a solution, not something that you have to constantly keep patching delivery. If you go back to the early days before the internet, when you actually sold software, the software had to go on physical media had to be shipped and delivered, and that was it. That was all there was really no such thing as a patch unless you actually had a customer call you and you had to ship them floppy disks, but in today's environment, it is way too easy to say it's good enough to ship and then get stuck in cycles of actually improving the product to get it to where it really should have been when it shipped. Now this is, I don't want to say that separate from an MVP. There's a difference from having a minimally viable product and selling it at your customers and saying, Hey, we are, this is version one. We, we are solving this problem and all we're going to do is we're going to solve that problem and solve it well, because then what you're doing is you're selling them on that problem, that solution. You're saying we're solving it. Cool. And they're going to say, and it needs to, that's the minimum viable, minimum viable product. Part of it is to say it solves it. It's sufficient. They are now happier people than they were otherwise. Then you can come out with version two and say, all right, now we're going to find a better way to, you know, to solve that problem, better way to skin that cat. But that's not the same as we're just going to throw it out there and you know, minimum viable product is for your users. It's not for you to just be like, okay, we're done. We want to at least get something out there and generate revenue. And I know, I know that is difficult with, uh, when you're in a public company or when you've got, you know, customers breathing down your neck or investors or things like that, it can get difficult very quickly. Moving on. Premature optimization example, spending days, optimizing performance when the product doesn't yet have users solving future problems, waste time. Ask, is this a problem we're solving right now? This I have had fights about because on some serious number of occasions because it's yes, that is important. No, that is not important right now. We are not there yet. If you're sitting there worrying about the colors and the font on your application and you don't even have all of the pages done yet, you don't even have any of the key features done yet, then you are your cart before the horse. You are not where you need to be. It does not mean that you don't want to think about those things. That does not mean that you will not be necessarily frustrated down the road when you're like, gosh, it would have been nice if we had known what all of these pieces were, you know, what these fonts and colors were before we built all these screens that could have made it nicer. But the thing is, is it, you didn't even know those screens were going to exist back then, so you probably would have spent a lot of time doing something that you really didn't need to do. And that, that is a really big developer piece is understanding when to actually execute on some of these tasks, because there's a lot of stuff. If you look at building applications, a lot of things that go on in building software, and there is essentially a time and a place for each of these. And it's easy to get sort of focused a little bit too much focused on like, well, we need to do this thing right now and not stepping back and going, wait a minute. No, we actually don't. And this goes back to something we've talked about earlier. It's like spending too much time upfront and not spending enough time towards you. Now you're at the end and you have all these things you have to have, but you wasted your time on stuff that you don't actually have. And you don't need to have, it's like, you know, it'd be one of those things where it's like you're jettisoning things. You're, you're spending too much resource, too much of your money early on. And now when you have to actually buy like, I don't know, food and clothing and somewhere to, you know, a house. Well, you already blew all your money out there and yeah, you've got like a nice toy or something like that, but you don't have food and clothing. It's the same kind of thing. It's just, it's resource management and it's making sure that you make sure that you're doing the right thing at the right time and not getting caught in those little rabbit trails, your thoughts. Yeah. We have both been in many, not us all the time together, but we have all been in situations where you may be trying to solve a problem and in the process of solving the problem, you're trying to be a little more forward thinking. For instance, if you are like working with databases or working with message queues, you may come to a point where it's like, well, we need to do load testing or we need to make sure that we can handle the load of these. Interactions, these integrations, integrated systems we have. There is a point within the life cycle of an application that yes, it is time to do that at the beginning, no, until you actually have enough of the systems in place where you can actually see how it works. It is not efficient at it's not worth your time or resources to spend the time testing that before you get there, because you might get there and that. Integrated system may completely change. You may find a different solution. So, especially in the early stages of a project, especially if you're like thinking, oh, we may look at this or we want to use this or we try to do use this. Don't get too involved in the testing, the load testing or feature set till you get to the point that it is fully integrated within the application. Yes, you want testing. Yes, you want to make sure it works, but don't go too far. Just make sure you got the basics and move on. I'll take this to another thing that's like an easy analogy or an easy example. Is spending too much time on the design of a page and the layout of the labels and the in the fields and things like that. When you're, you know, when you're early on, when you're just putting that thing up. Because there's a lot of times that some of those fields will disappear. Some of the labels will change anyways. Maybe that whole screen or page will go away at some point. There are a lot of things that can happen where you end up and it's, it is a little bit of a crap shoot. There's going to be times where you're like, ah, it would have been nice if we had spent more time on this early on. But your goal is to not waste your time on things that end up not being part of it. You don't want the stuff that ends up on the cutting room floor to be stuff that you spent a lot of time on. You don't want to be like at the end of like you've created this big movie and you spent 90% of your budget on a scene that now you were not able to do. I've seen that now you were not even going to use, you know, something like that. That's sort of where you can go with some of these. You can get way too lost in the weeds and not realize that some of these things, you don't really have a firm enough. It's not firm enough yet where you're going to go to really spend that time on it. Now I want to add onto that though, because there are some benefits to some pre-planning. So at the big, not in the middle, but at the beginning of the project, throw everything at the wall, literally. Like any idea, get it out there, wipe board brainstorm as much as you can. But then as Rob mentioned, get it to the point where you whittle down to what you need for the MVP and then cut the fat. But try to spend enough time at the beginning to maybe a day or two, but have enough people talk about the idea so that you cover as much as you can to then cut it down to what you actually need. Because if you don't do that, you might literally miss a key feature that you need that you get to the end and you're like, oh crap, I now need to build this really quickly or we're not delivering. And this goes to the, I'll throw the other ones out real quick and then do a little wrap thought here. Is it wrap up? So problem solving is an exploration, not execution. When solutions create new problems, we see that all the time, start with the outcome, not the output and redefining success. Now I've got a couple items that we'll probably cover in the bonus we do in the after the audio wraps up and we have the post show video. But the thing that we sort of a theme that has come through a lot of these is spending the right amount of time on things is you don't rush it. Don't jump in and just be like, okay, I'm like checking stuff off. That's really more of a coder kind of thing to do. Developer is going to say, you know what? This is not a science. This is, there's definitely an art to this. And sometimes it takes a little time for things to bake in for the right. Creative juices to start flowing things like that. So spend your time, like take a step back. Give the tasks that you need to do the, the amount of time that they need to get them done. Don't try to rush your way through it. Don't try to cram, you know, a square peg into a round hole. Allow things to go the path they need to. Yes, you're going to have to push sometimes. Yes, there's going to be stress. Yes, there's going to be times you're going to like do more than you want. You know, spend more time on something than you want to, but make sure that you're not often spending less time than you needed to. I think that is where we end up kicking ourselves way too often for doing so. Also don't kick yourself for not sending us an email. Shoot me an email at info at developeronurl.com and let us know your thoughts. What are some of the things that you've run into? You know, whether you listened to this a couple of seasons ago or whether you're listening to it now and you're like, Oh, this AI thing really has got some great ideas. I should look back. It probably has better ideas than we have, although we are, we are like lining up. So I'm feeling pretty good about it. That being said, I'm not going to poke you for any other stuff. You know where to see us. You know where to leave us feedback and all that goodness, whether it's at developer on a YouTube channel or podcast, wherever you get podcasts. Also, if you find it somewhere that you get podcasts and we're not there, let us know when we want to make sure we're there. As always go out there and have yourself a great day, great week. Thank you for listening to building better developers, the developer 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.