221. Learn How To Simplify Difficult Tasks In Software Development

How do I handle a difficult task in a sprint? How do I stop from being overwhelmed by complicated projects? What do I do if the requirements aren't clear? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

How do I handle a difficult task in a sprint? How do I stop from being overwhelmed by complicated projects? Working as a software developer, you're going to face overwhelming projects a lot. In fact, it's a big reason why the role exists in the first place. If our job was easy, we wouldn't be needed. People using low-code or no-code solutions would have replaced us by now. So when you're faced with a complicated, confusing task, how do you solve it? In today's episode, we're going to talk through how to overcome difficult tasks.

SPEAKER_00 0:42

Welcome to the Dev Questions podcast with Tim Corey.

SPEAKER_01 0:46

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to simplify difficult tasks instead of getting overwhelmed. Now, the answer to this really comes down to just one thing. And I know you're used to lists and other things or possibilities. It's just one thing. Break the problem down into manageable chunks. That's it. That's the whole thing. And if you want to stop right now and be done, that's fine. But I'm going to show you six different ways of doing that. Okay? You can solve almost any problem, regardless of its size, if you just break it down into smaller chunks. So let's talk through how to do that. Now, I'm going to give you an example from my life, and I've told you four, I think, at least once, but it's probably the clearest example. I've got lots of examples of doing this, but this is one of the clearest ones because of how overwhelming it was. So I used to work as a basically a I worked for a company that would then contract out my services. So we were a consulting/slash work for hire type company that would come in and solve software development problems among others. I ended up working as a network engineer as well and other things. But we would solve problems when it came to technology. And we had a company come to us and say, hey, we've got a whole bunch of conveyors that we want to stop and start at any time from anywhere. Now, if you're not familiar, in most industries, it really should be all, but in the industries where you have conveyors and other working, moving machinery, you have a button that's prevalent that's called an e-stop or emergency stop. And it's usually a big red button that you just hit with your hand and it will turn off the machines in that area. And that's a safety thing. So let's say you get your hand caught in something, you want to be able to hit that button and stop it from being pinched further or causing further damage. So that's a physical button at one or more physical locations. But when they were working through what they wanted, they said, hey, we've got these wireless devices. Now, if you're not familiar, they're called PDAs at the time. Okay, this is back in the early 2000s, or a handheld computer, basically. Um, but it was a digital assistant, what the thought was. Um this device you held in your hand that barely could do anything. But what they wanted to do was use that wirelessly to turn on and off conveyor systems. So have that e-stop capability from wherever they were from a wireless device. Here's the problem. Wireless was barely a thing at the time. Handheld devices were barely a thing at the time. And so the technology didn't really exist to put the two together. In fact, my boss, you know, bid this out and then came to me and said, hey, do this. And I did some research and I said, hey, you know, there's companies out there that are doing this. In fact, one of the largest in the world is building out software like this, but the buy-in for the beta program, which isn't up and running yet, but will be hopefully in the next year, that buy-in is one million dollars. Our customer did not pay us nearly one million dollars. Okay. Um, take a couple zeros off of that, if not more. Okay, so if big companies are doing this for millions of dollars and they're not even ready to do it yet, how can I implement this? And he's like, I've got faith in you. Okay, that was an insurmountable task. But what I ended up doing was I ended up breaking it down into chunks. So I I knew we had wireless PDAs, okay, PDAs that could talk to the network. All right. So I know that that's where I want to control things. Well, that PDA, I couldn't put a lot of apps on there. There wasn't, it was not easy to do that, but I could put a web page on there. Okay. It had a browser. So, well, I can build a web page. So that was my next step. I I said, okay, I've got the wireless device and I've got a web page I can put on there. Well, I can build a web page that has interaction, interactable buttons. Okay. So now I know I can get that done, and I know that I can put a server on the network that have a local uh web page that I could serve out. So I could build out a ASP net, or actually it's ASP at the time, not net, um ASP web application with the list of conveyors from SQL. Okay. So now I've got the list of conveyors on the wireless device based upon dynamic information from SQL. Okay, so we're getting steps further, but you might think, well, Tim, but that that's not control yet. No, you're right. We're breaking it down into pieces. So now I've got the ability to have an app on the IAS server on a server that can send information to the PDA. Next up, I built a command line app that read the status of the conveyors from the control system. Now that was on a different machine. So now I've got a different machine with a different app that's a command line app that runs all the time that reads the status. I believe it was every second or so, it would read the statuses of all of the different conveyors. And then I had that application update the same SQL database. So now the SQL database has the live status of all the conveyors. And so then that gets displayed on the web page, which then gets put onto the PDA. Well, then I started working on having buttons on the web app that could say turn off or turn on, based upon if it's off or on, um, the conveyors, basically an eStop. And that's in the information into SQL. But then I had the command line application read from SQL on a recurring basis all the new command updates. And then would take those command updates and it would send them on to the control system. So now I can push a button on a web page on my PDA, and that information goes through SQL into the other application, into the control system, and turns off the conveyor. And the opposite was true as well. Okay, so I got it to work and we got it working for the customer in a way that they that they approved of, they liked. And yes, it was kludgy. Yes, it had multiple steps along the way, but we were able to do something that those very large companies were still struggling to figure out how to do. Now, when they came out with their applications eventually, they were probably better than mine. I'm sure they were better than mine. But we got something that worked for the customer and was successful. We meet, we met the requirements by breaking down the project into small chunks. So let's talk through the different ways to break down a problem like that. Okay, I'm gonna highlight six of them. There are others, but these are kind of the major ones. So the first one is to break it into big chunks and then break each big chunk into smaller chunks. Okay, so for example, let's say you were gonna create a Twitter clone. Okay, well, that's a that's a lot. Okay, there's a lot of stuff in there, and people think that a Twitter clone would be super simple. It's not. There's lots to it. But let's break down into big chunks, okay? Well, there's authentication, there's push notifications, there is users, there's tweets, there's interactions, and there's advertisements. Those are big chunks, okay? And you couldn't necessarily just do one chunk as it is, but you've broken it down into smaller, smaller uh chunks. We can then break down even further. So let's talk about push notifications. Okay, so you break that down into smaller ones, like um when to notify, um, how to identify if a notification should go through or not, um, and so many other things. You break that down into smaller bits, and then you're able to build each of those bits, and then you have the push notification system. And then from there, you build the next system, the next system, and you've you've broken it down to very, very small chunks that you can then digest. Number two, um, this works well when you have clients you're working with who are not technical or not as technical. And this is when you sketch out the user interface. So this can help reveal what the application might look like and kind of help break it down into smaller pieces. So you sketch out the user interface and they start to see, oh, well, I would need to have this information there and that information there. And it starts to reveal what information you need and what pieces you might need. And then you've you can say, okay, I can I can do these pieces. Uh so for example, if you watch through the suggestion app application we built on YouTube. Well, we built that with a UI sketch first. So we sketched out the UI and said, okay, here's the pieces we need, and that kind of helped inform the instead of one big application. Well, now you've got the various pieces we need we can build from there. Number three is the opposite way. Okay, you structure out the data and you say, here's the data we need, and that helps break down the the big complex thing you have to do into okay, how do we get this data? How do you update this data? And you go from there. For example, maybe you are uh working on a realty site for selling houses. Okay, well, maybe you figure out what data you need to collect, and then from there you start building the structure and go, okay, now I need to know how to collect this data. Now you know how to display this data, and it starts to give you more of a structure of what you need to do for that overall task. Number four is you work a direction. Okay, you go from the start to the finish or the finish to the start. For example, the um the wireless conveyor system I built, the wireless conveyor control system I built. I went from kind of the end, which was the handheld PDA controlling things, and I worked backwards until I got to the point where I could send data from that farthest back piece all the way through to the controller and then to the PDA. And then I could send data from the PDA all the way back through to the other end. So I worked from one end to the other, breaking down piece by piece and not worrying about everything, worrying about just this part, and then one step previous, and one step previous, and one step previous. So working in a direction. Number five is cut off chunks. Okay. So maybe it's a big, massive application. You got to do tons of stuff, it's overwhelming. Um, and you say, you know what, I'm going to break off the pieces that I know I can do. Um this is easiest if maybe you're building a microservice-based application, or you're going to build lots of microservices. Well, okay, maybe you don't know how to do everything yet, but you can build a microservice that sends out emails. And you can build a microservice that you know um does talks to the user or gets information from the client or takes orders or fulfills orders. Like you start breaking it down, and then what you have left is a smaller chunk than when you first started. And you may still have a pretty large chunk, but it's you've taken the easy stuff off the top. Then you can use our techniques and break it apart into bigger chunks or work from one and the other or something else to break that big chunk into smaller chunks and then do those little pieces. Number six is identify and eliminate the unknowns. So, one of the reasons why a big complicated project is scary or a big complicated task is scary is because you have a whole bunch of unknowns. So maybe let's go back to the Twitter um example. Maybe you're just going to do push notifications and you think, wow, there's a lot to push probably. And actually, I don't know if you know, but there's like 50 steps to push. It's not just do I push or not. Um, lots of steps. So if you're doing that, you're like, I don't know everything I need to do. Well, that makes it very, very scary and very, very difficult to know how do you estimate how much time it's going to take and how do you even go about solving the problem. So identify and eliminate the unknowns. If you don't know how to do, let's say, authentication, build out a demo for authentication and figure it out. Okay. This is why you should be building and practice projects a lot. Practice projects help you eliminate unknowns. When you eliminate unknowns, well, then things become clearer and a whole lot easier to do. So that's number six. Identify and eliminate the unknowns. Now, you can mix and match these six techniques in order to make your problem more manageable. It's not just one technique or the best technique. Mix and match. Okay. Maybe you break your project into smaller chunks, and then you know, one chunk might be something that's more UI related. You create, you know, the UI sketches to help break that down even further. Another one might be where you break off pieces that you know how to do. Another one might be you eliminate some unknowns. Whatever the case may be, you mix and match these techniques in order to make your problems more manageable. Now, one key part of this is to identify and eliminate those assumptions as well. So, yes, maybe there's unknowns, but sometimes there's assumptions. And assumptions can really bite you. Because maybe you assume that the application is going to work with SQL database, but that's an assumption until you figure it out. Or maybe you assume that it's only gonna be this scope and actually it's a bigger scope or a smaller scope. I've had that happen before where I get overwhelmed by, oh my goodness, there's so much to do, and I find out, oh no, I'm just doing a little piece of it. Well, that's a big deal different, and it changes how complex the project is. So the above methods are gonna help expose the assumptions. So the six different techniques, but then get clear resolution of those assumptions before continuing. So don't just allow assumptions to linger. Make sure you eliminate them as you break the project down, as you work through breaking that project into more manageable chunks in order to understand it better. Okay, so make sure that you don't have assumptions. All right, so those are six techniques to help you with overwhelming projects or overwhelming tasks to break it down into much more manageable uh pieces that you can work through and estimate as well. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 16:36

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to imtimcorey.com and enroll in a course.