Solving Problems Without Solving the Problem

Welcome to Building Better Developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we're talking about effectively we're talking about the developer journey and building a better developer you start from obviously not being better to being better and notice you never actually finish that journey to better. Before we get going too far though, I need to introduce myself. My name is Rob Brodhead, one of the founders of Develop-a-Nor, Building Better Developers, also founder of RB Consulting where we do all kinds of nice little software stuff, mostly integration simplification and automation and sometimes it's communication like with the man on the other side, Michael, go ahead and introduce yourself. Hey everyone, my name is Michael Milaj. I'm another co-founder of Develop-a-Nor. I'm also the founder of Envision QA where we help small and mid-sized businesses build custom software to software assessments and also help small clinical offices build medical solutions that help their systems. This episode, we're sort of continuing on a little bit of our journey as we've gone through some stuff. We've talked about problem solving essentially last episode around and so this episode, we're really going to talk about how do you solve the problem without solving the problem because this is something we do run into on a regular basis. We may have to write it up. We may have to design something. There may be a proof of concept or a demo or something like that and some of it is how far do you go? Where do you find the, where do you draw a line between doing something and doing it for real? And this is often going to be a situation that will come up if you end up in that side hustle industry where you're putting proposals together and things like that. Somebody's going to say, hey, can you do this for me? And you'll say, yes, I can. And this is how I can do it. And then they'll ask for a little bit more and sometimes they'll ask for a little more and a little more, a little more. And next thing you know, you've halfway built their thing. It's like, look, we've already built it. We've already put maybe hundreds of hours into this. At some point it's like, you know, fish are cut bait. You're either accepting this project or moving on or we're not. Then you also don't want to give too much away. I mean, it'd be like a lawyer. If they ask you for, you know, you're like, hey, can I get a little bit of advice? And basically you ask them for all the advice you would need to be a lawyer, then they've just given it all away. And it's like, well, wait a minute, that's not free advice anymore. You just stolen my knowledge. And it's not quite to that level, but it is something along that way because you need to often you need to step into a problem, start working that problem, maybe think through some of the solution, put some of those pieces in place, maybe even test them out through a proof of concept and then move forward because you don't want to put too much into it. If one, the project's going to be canceled or two, they're going to go somewhere else or three, it's not a good solution. Sometimes we get into this and we say, here's a problem. Here's a solution. We get sort of into it and it becomes not feasible. An example that I've run into lately is working with a tool that was gathering data. And we looked at, initially it was like, well, here's how you're going to gather data. Cool. That makes sense. It's like, we're going to go from these sources and this is what we're going to get and it's going to be awesome. And we're going to pull this all, all this stuff in. Well, it turns out as we get a little further into it, a couple of those sources, their APIs were too expensive. It was too limited. It was going to be too cost-worthy, too much of a cost. So we had to go like a different route and then we go the different route and we're actually getting too much data because we're doing stuff like search engine hits that are bringing back pages and pages of data that might be useful but probably aren't. And it takes a lot of resources to mine that data to try to find the bits of information that we're trying to. And so in each of these, there was, it's effectively a proof of concept kind of things. We're like, go in it, grab some data, put it together, let's see how it looks, let's run it a few times, let's run it for something in a, you know, like a small batch of data and then grow to something bigger and see, does that scale? And that's usually where you're going to find out the issue, which is my first recommendation in this is that you start small, super, super small, like, you know, one or two records or something. It's basically, prove the process once. Can it be done once in the most simple, simple kind of situation? And then let's see if we can generalize that so we can open that up a little bit more and make it a general solution and then try to look at what does that general solution look like if you apply it to a larger or maybe a real world, maybe not fully real world, but a closer to real world set of data. For example, if you're building something that all it is, is taking in data from a CSV file and it's parsing it and putting it somewhere, start with like three records. Just go in, do three records, run through those, see if that works right. If it does, okay, now let's open it up to 400 records or a thousand records or something like that. And then maybe it grows to, okay, I'm going to give it 10 different files and they've each got a thousand records. Then you're like, okay, this scales. And also whether it scales or not, you are going to be able to see even in the most positive say that, okay, this is the growth curve of it. If I've got 10 records, it takes a microsecond. If I've got a hundred records, it takes three microseconds or whatever it is. And it's, so you'll be able to see if that progression continues. Is this some sort of curve that's going to just go off into space or is this something that's like a nice curve or a nice progression line that I'm like, oh, cool. I know that I can do 4 million records of this in X amount of time. So the first thing is what's your solution when you're doing that proof of concept? The first thing I'm going to say, what are you trying to prove? What you trying to prove, man? It's not one of those. It's not like you're going to get your fists up or anything, but it is something where it is, I have a problem. I've got a solution and making sure that you're sort of, as you're going through this, you're keeping in your head or you're keeping the questions you want to answer is where would this solution not be useful and use those things to drive your demo or your POC? I'll throw it to you because I've talked too much already. So what are your thoughts or maybe recommendation you have? Yeah. So to kind of build on that. So I liked your idea, you know, as you're starting out, you're trying to figure out that proof of concept, you're trying to figure out how something works. The example you gave is a very good example of test-driven development. Figure out your problem and then work backwards to your solution. So like you said, start with a small data set, make sure that works and then work your way up to the larger data set. Tacking onto that, while you're doing your proof of concept as well, when you're working on trying to figure out this problem or how to solve this problem, you don't always have to go out and build a solution. Sometimes you can go out and find APIs or projects out there that already exist that solve the problem for you. You don't have to always go out and reinvent the wheel, but there are cases where sometimes that's a necessity. Like if you're in healthcare, maybe you can't use these APIs because they're not secure enough or they might be open and you might run into some HIPAA violations or some SOX compliance issues. So don't just look at, hey, how do I solve this problem with building it from scratch? Can I use other tools to build this? Are they compliant with the environment I'm working in? The other thing is, as you're putting this together, I had a very good case of this and this was years ago, Robin, I think this is even before I first met you at the company we worked at, was I was approached with an idea of how can we take this billing center model that we had within the company? We had like 20 some billing centers across the country that was handling all the claims information, the customer information, the order information for medical supplies. And the whole problem with the process was it was very manual. So I was tasked with, okay, how can we take this manual process and automate? How can we turn this into a program where instead of people passing papers or binders around, how can we turn this into a desktop app or web application that we can solve, that we can essentially eliminate this problem? So we started out analyzing what the business did. What is the problem? What are the processes in this particular case? We were trying to replicate what someone was already doing, but we were trying to do it in the software model. As we went through this process, they were like, well, here, let's just start with the binder and we literally just replicated the worksheets that they essentially had into a web application. Everyone loved it. It looked great. Problem you run into with this sometimes is as you're building these solutions, suddenly you find yourself in a situation where you are now with a live application. So somehow along this journey, you've gone from this proof of concept to, oops, you're now live. You're now supporting something that's not quite done. But to get there, this does happen, but you have to be mindful, like Rob said, as you're going through this process, you don't want to give away everything. But you also have to be mindful that as you're putting the pieces together, that you don't find yourself in a situation where, oh, someone higher up sees this and says, great, let's stick it out. They're live tomorrow. And you're like, whoa, I'm not ready. This is all mock data. Let's take a step back. How would you, from your perspective, Rob, how would you avoid that situation? What advice could you give to our viewers? So to answer that question specifically, this is something that we see on a fairly... I used to see it, I think, more than we do now. But as I'm thinking about it, no, I actually do see it fairly regularly because we have actually, we have a whole process now that is built to address that. If you are in the world of Agile and Scrum in particular, the whole point is that at the end of a sprint, you have a deliverable. You have something that technically is useful software at the end of every single sprint. And so it actually, instead of circumventing that or trying to see that as a problem, it owns it and says, cool, this is something we need to deal with. And actually says, all right, we can actually get the train on the tracks and start moving forward. And it seems like a bad analogy, but they're like, we can start building onto the train as we go. And sometimes that's very difficult, but it does allow that. And actually, particularly in the web application world and some of those, even a little bit desktop, but definitely in the SaaS world, it makes a lot of sense because you can put together a nice framework of stuff, a really focused solution, and then build on top of that. And now this does sort of step into this proof of concept thing. Sometimes the proof of concept is, for example, this is the application I was just working on. The first proof of concept was like a page. It's just you bring up a page, you enter some data in, you hit a button, it goes and does some stuff, it kicks results out. Very simple, not very pretty, but it turned out to be almost the entire first phase of the project. And so it was like, oh, OK, we're just going to add on this and this and this and this. Now when we started to add on, that was when we started having problems. Now this is where there are some very powerful tools out there. Now some people go zero code approaches. There are some of the things out there that will allow you to do, or even like a Figma or something like that, where you have images, you have a clickable demo, you can make it look, you can roughly approximate user experience and look and feel and all that kind of good stuff. And that allows you to make this a selling point as opposed to like a point of caution. Now before we, I don't want to miss one of the things that Michael brought up, was the idea of, it really is almost a precursor to this point, is when you're solving that problem, one of the things that I think it is, especially these days, because problems are not unique very often. They may be specific to you, you may have a specific need, but generally speaking, there's a lot of stuff out there that are also general problems that everybody sees them, especially when you go to like a specific silo. Like healthcare, it has, it's a whole family of problems that almost everybody in healthcare will talk about it. They know it, they exist. It's just, that's part of what it is. Likewise in finance or automotive or you name it, real estate, you name it, whatever it is, there's that set of problems. And there are billions, okay, maybe not billions, lots and lots, more than three developers out there in the world that are cranking through this stuff. And there's commercial software out there. It is, that's one of the things I think that if nothing else, when we were going through all of those interviews and that long season or two, there are a lot of people we talked to that had very niche software services and products that they did, but they also had a large number of customers. So it makes sense in the ancient world of there's build versus buy. And I think that still exists to some extent, but also there is the proof of concept, the partial solution. A lot of times it is you go out and maybe you buy, but you can customize or it's buy and extend or buy and customize or maybe open source and customize. There's different levels of risk, of costs and of return on investment and all these other, there's a lot of factors that go into these, but when you're considering your solution, and maybe this is part of what your proof of concept is, is really proving, does it make sense for us to build this or does it make more sense to buy it or does it make more sense to go to one of these products that's out there that provides it? A lot of times I've gone through several RFP processes where that was really upfront. That was sort of the front loaded thing was, do we actually go to an RFP? And if we do, we need to know, or it's very helpful to know, this is what it's going to cost for us to build it. This is what we see in the market. And here's what we're actually looking for, because sometimes you are looking for, I need this solution. I need a product that I can get off the shelf that gets me 80% of the way there. But to be useful to me, these are explicit customizations or features that I need to get me across the finish line for myself. Now I took a while and I went off on a rabbit trail. So I do want to swing back around and say, did that get you that answer the question of what you're looking for and allow you to tack onto that if you, if you, for a follow-up. Yeah. A lot of those situations, now I know we touched on agile and some more complicated things. In the more depth of those along the journey here, but that's the idea. The problem, as you addressed through using particular development frameworks or development models like agile is those are designed to prevent that. But there are still situations where, hey, I've got this idea or I've got this problem. I start working it. You can be working in a silo and suddenly, oops, you now have the solution. And like I said, you're now live. So you kind of, you do run into situations where you do come across kind of one-offs where you kind of fall outside of the traditional model. It could be by chance. It could just be a happenstance. Those are good things to happen because when you run across that, it's good and bad. It's good because yes, you've solved the problem. People like your solution. They're ready to go run with it. But sometimes it's, you know, we got to learn to walk before we run. But sometimes you're running before you're walking. It's like, whoops, you're already out the door, gone. And it's like, what just happened? But don't be afraid of those. Thrive on those. I love looking at new technologies. How does that work? It's like taking the TV apart and trying to put it back together. It may not always work, but you figure out how the inner workings work. And so the next time something breaks, you can figure out how to move on, how to make it better, how to integrate that next project. Or go to your boss and say, hey, I heard you had this problem. Let me take a stab at it. Go figure out how to fix this and come up with a solution for you. Let me do a POC. And that, I guess, just some closing thoughts on this one as we wrap this one up, is that you do want to embrace that. If somebody comes to you and says, hey, I need you to solve a problem, and you give them a solution. If it's something that looks like they're going to push that out there sooner rather than later, then that may be okay. That may be awesome. You may suddenly be able to retire a lot earlier than you thought you were going to. Or maybe a major headache. And so when you run into those situations, I think this is something we will come back to and focus more on in another episode. But there is, in a lot of cases, there is a cost once you are live with things like updating data, maintaining data, replicating data, and all that kind of stuff. Because now as you build and then even changing data, this is something particularly changing that I have seen in a lot of projects. And there's one in particular that I work with this customer we had a solution and we're like, cool, we're going to do this. And we got further down the road and we changed the solution. They're like, wow, we really need it this way. And I was like, cool, that makes sense. The problem was we didn't really think through, didn't really understand how much impact that was going to make. It's one of those where like, oh, it's going to be a couple changes here, couple changes there, field here, report there. But it wasn't until we got further into it and realized that there was relationships and things within the data, particularly with the existing data that we now had to migrate out of. And it was a very painful, tedious process to do it. So there's some things like that that you want to be aware of that you may be biting off more than you can chew. And particularly when you want to get that solution out, they want to get the solution out. Sometimes it's easier to say, you know what, we'll just, we can put that down the road and we'll tackle that data later. But in particular, data and data structures have their own weight and momentum. And there may be a migration you have to do in your future. And we've seen it in every piece of software out there that goes through major releases. Eventually there's a watershed or something where you have to actually migrate into the new system. What you don't have to do is migrate to another podcast because we're here. You can take everything you've heard from us, from all of these hundreds of episodes, and carry it forward into the next episode. So check us out wherever you subscribe, wherever you do your podcast. You can check us out on YouTube and check us out on developerneur.com. You can shoot us an email at info at developerneur.com. Like somebody we're going to highlight, we'll say in the next episode, where we've gotten requests from out there and got some good questions that we can talk about. We would love to take those from you as well. That being said, I want to respect your time. So go out there and have yourself a great day, great week. And we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Neur 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.