Detailed Notes
Welcome back to episode 3 of Season 22 of our Building Better Developers podcast. In this episode, we continue exploring problem-solving strategies. Previously, we discussed general problem-solving approaches. This episode delves into a nuanced topic: Solving Problems Without Solving the Problem. This concept frequently arises in various professional contexts, particularly in project management and consultancy.
Read more ... https://develpreneur.com/solving-problems-without-solving-the-problem
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources
* One Offs, Side Projects, and Veering From Standards (https://develpreneur.com/one-offs-side-projects-and-veering-from-standards/)
* Setting Realistic Expectations In Development (https://develpreneur.com/navigating-realistic-expectations-in-software-development/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
Transcript Text
[Music] button hello we are here we just hit record so I'm going to say hello uh we are talking about our topic for today the initial thing I pitched and I'm sort of like reading this as we go uh two things I pitched well thing I pitched I guess for now would be basically talking about doing a a presentation of of some basically like doing an assessment and what are some of the challenges that you were run to run into um it would be you know it is really it's out of order from what we're doing I do think it's part of the developer Journey um but I think it's also going from instead of starting early developer Journey we're sort of jumping ahead to later development journey and it's mostly because it was on on my mind I can't imagine why but uh it was you know something that is near and dear to us right now and I think it's I really think that this is is one of those things that is in general a good conversation point about communicating stuff because I think we have even if you're not doing like a full-blown assessment of something you are often asked to like you know talk about your app that you did or maybe do a demo especially now in the world of of uh agile and scrums and Sprints you are asked on a regular basis and maybe this is how we you know we narrow it down a little bit more to a developer but you are asked on basis to demo your stuff and to walk through it and how do you show this and how do you address the needs of varying audiences now this yeah an assessment does get a little bit more definitely into advanced developer stuff because it's where you're like okay you may be talking to a CEO or something like that but there's there's a lot of little pieces to this that I think are useful for us to to talk through which is why I pitched this out I think we could come back around to it later um that was sort of what I was going with this one um yeah and I was reading your notes on that and I I kind of feel that this is more an advanced topic like we probably for the assessment piece talk more about that maybe 15 episodes in or 20 episodes in at this point though if we want to kind of stick to this theme a little bit though we could get into uh all right so we kind of talked about about going from coder to developer problem solving so the next progression of that if we follow your train of thought but bring it back to the earlier part of their Journey let's talk about you know all right so now that you're solving problems now you're working in an an environment where you have to solve these problems how do you go about researching how to solve that problem how to put together like a proof of concept and then how to pitch it to whoever as your solution I think that works I think that's something and it's this is one of those areas I think we'll come back to a couple times from different points of view so I like that so we'll work so this episode uh which actually sort of goes the second one that I wanted I was thinking about that'll be that next episode um so sort of basically start with we got a problem all right how do we actually show that we're solving that problem before we solve the problem effectively um you know how to which is things like proof of Concepts and demos and those kinds of things and then the the second one I wanted to get into anyways I think May dovetail well with that is sort of a okay what happens when you say hey here's the problem we're going to solve and here's how we're going to solve it and somebody's like no no no no we're going to do it completely differently and dealing with that because sometimes it's a customer and it's like customer's always right sometimes it's somebody at work where it's like okay this person's always picking a different path how do I deal with this you know it's not it's not quite the poison pill person where it's somebody that you're just poisoned everything it's just they are your Nemesis or something like that where it's like you get into stuff and everybody and people will especially early on you're going to see that in a company where you're you know this is the right way to go this is like you've been taught this is how we have to do it and they go a different direction so it's how do you work within that and you know it's the kinds of things like making sure that you don't get yourself in a bad situation because you've overreacted to it and it's also and some of it's you know keeping an open mind and some things like that and and figure out where you can learn and where you can work within a maybe a very different framework than what you're used to so that actually is near and dear to my heart because I'm dealing with that right now I'm working on a program I have a very tight deadline um it's with creating worksheets I'm having to create a new worksheet on the fly right now we don't have the backend data yet so I'm having to mock all this and I come to find out that all the data objects that we're using to generate the reports are not domain objects they are reusing the dtos that we received from all of our API calls and they were not reformed into a structured format so I'm having to go through hoops to build essentially the domain object or the report from all these different locations of data yeah this is actually something this was a this came in on the request line from Timothy from Oshkosh Wisconsin there was like brought it up and I was like one I'm G to use your name and two that's a really good idea because that is something we run into and he mentioned that yeah you may know something about that yeah I no I like that okay so that's where we're going to go we're going to start with like how do you show You' solved your problem 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 on going too far though I need to introduce myself my name is Rob rhead one of the founders of developing or 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 molash I'm another co-founder of developer Nur I'm also the founder of Invision QA where we help small midsize businesses build custom software do 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 bit of our 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 uh we may have to write it up we may have to design something there may be uh a proof of concept or a demo or something like that and it's how far some of it is how far do you go where do you find the where do you draw line between doing something and doing it for real and this is often going to be a situation will come up if you end up in that side hustle industry where you're 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 no 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 Fisher cut bait you're either accepting this project we're moving on or we're not and you also don't want to give too much away I mean it'd be like a 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 it's like well wait a minute that's not free advice anymore you just stolen my my knowledge and it's not quite to that level but it is something along that ways 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 cancelled 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 the problem here's the solution we get sort of into it and it becomes not feasible an example that I've run into lately is uh 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 wasn't going to 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 you know 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 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 thing so I 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 like 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 General 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 th000 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 the most positive say that okay this is the growth curve of it if I've got 10 records it takes a microc if I've got a 100 records it takes three micros seconds 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 you know curve or nice progression line that I'm like oh cool I know that I can do four million records of this in x amount of time so the first thing is with your solution when you're doing that proof of concept the the first thing what are you trying to prove it's right 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 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 you're keeping in your head or you're keeping the the questions you want to answer is where would this solution not be useful and use those things to drive you know your demo or your POC I'll throw it to you because I've talked too much already so what are your what are your thoughts or maybe recommendation you have yeah so to kind of build on that so you I liked your idea you know where 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 tching onto that what 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 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 health care maybe you can't use these apis because they're not uh secure enough or you they might be open and you might run into some hippo violations or some socks compliance issues so don't just look at hey how do I solve this problem with my with my you know 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 uh I had a very good case of this and uh this was years ago Robin I think this was even before I first met you at uh the company we worked at was I was approached with an idea of how can we take this uh billing center um 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 uh 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 it 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 or web application that we can solve that we can essentially eliminate this problem so we started out analyzing what the business did you know what is the problem you know what are the processes in this particular case we were trying to replicate what uh 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 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 cont concept to oops you're now live you're now supporting something that's not quite done uh 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 there live tomorrow and you're like whoa I'm not ready this is all mock data uh you know let's take a step back you know how would you from your perspective Rob how would you avoid that situation you know what advice could you give to our viewers so that to answer that question specifically um this is something that we see on a on a fairly I used to see it I think more than we do now but as I'm thinking about it now 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 it's 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 in the particularly in the web application world and and some of those even a little bit desktop but definitely in the in the SAS World it makes a lot of sense because you can put together a nice framework of stuff a really focused solution 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 um like for example this is one the 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 you know was like oh okay 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 uh or even like a figma or something like that where you have an images you have a clickable demo you can make it look you roughly approximate like user experience and look and feel and all that kind of good stuff and it allows you to make this a selling point as opposed to like a a point of caution now before we you I don't want to miss one of the things that Michael brought up was the idea of you know 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 the problems are not unique very often they make 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 in a a specific Silo like healthcare it has its 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 um 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 bons 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 it that if nothing else when we were going through all of those interviews and in that long season or two there are a lot of people we talked to that had very Niche software uh services and products that they did but they also had a large number of customers so it makes sense in the 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 that is you go out and maybe you buy but you can customize or you know it's buy and extend or buy and customize or maybe open source and customize there's different levels of risk of cost and of you know return of an 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 and a lot of times like 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 you know 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 a cross 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 the way you're looking for and allow you to tack on to that if you if you for a followup yeah and a lot of those situations now I know we touched on agile and some more complicated things we'll get into more depth of those along the journey here but that's the idea the problem as you addressed through you 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 but s you know you could 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 uh could be by chance it could just be uh happen stance but those are are good things to happen because when you run across that um 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 that's you know we got to learn to walk before we run but sometimes you're running before you're walk it's like whoops you're already out the door gone and it's like what just happened uh but don't be afraid of those thrive on those you know I love looking up new technologies how does that work you know it's like taking the TV apart and trying to put it back together it may not always work but you know 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 you know go to your boss and say hey I heard you had this problem let me take the stab at it go figure out how to fix this and come up with a solution for you let me do a p 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 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 you know a lot ear than you thought you were going to or maybe a major headache and so you run into those situations and we'll I think this is something we will come back to um and focus more in 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 worked with this customer and we we had a solution and we're like cool we're going to do this and we came got further down the road and we changed the solution they're like wow we really need it this way 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 you know relationships and things with within the data particular with the existing data that we now had to migrate out of and it was a very it was a very painful tedious process to do it so there's some things like that that you want to be aware that you may be biting off more than you chew you can chew and particularly when you're 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 punt 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 you know subscribe wherever you do your podcast you can check us out on YouTube you can check us out on developer.com you can shoot us an email at info developer.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 and bonus information is there any bonus material your thinking of yeah actually so as you were kind of giving your final thoughts just kind of jumped into my mind as you're doing proof of concept one of the other things to be mindful and we all do is like oh great let's go figure this out so you quickly or maybe slowly figure out the solution to the problem make sure you are a little methodical with your documentation your structure and your notes as you go through the process of your POC there's been many times I've been bad about this I've seen a lot of people where you get so excited you get to that solution then you're like go back and you try to maintain it and you have spaghetti coat or you have no idea where the heck you found that solution or this one thing that is what you need to do it as you go through the process either keep track of your browser history keep track of your bash history but just take the time maybe give yourself some checkpoints at the beginning at least to document what you're doing create a readme file but just do something to keep track of everything you're doing every so often so when you do get to the end of the POC if it happens to go live you have a way of maintaining this not like oh my God how the hell did I do this moment yeah that's where I've been in that couple the refactoring can get to be pretty nasty um the biggest Pro and this becomes multiplied as an issue if you have multiple Developers for example I've got an app I was just looking through not too long ago that we built we built it quick we did a lot of stuff we're making a lot of changes and I was looking through the code and I was really confused because we had three copies of the same method the same function was sitting there they're basically almost back to back to back and somewhere along the way we had missed that hey we already have that so code review would have caught that theoretically um also there should be some level of seeing that if you're doing if you're really focusing on like pull requests and and committing code again it does go back to some level of code review but these are kind of things as you're building them try to you know keep some notes use the docent particularly if you've got built-in documentation tools like Java do or something like that is just you should be in the habit of doing that kind of documentation at the very least like I do I do like daily standups if you've got a little status or something that you can go see what was your standups then maybe you can see what was you know done along the way or use like if you're using Trello or jro or you name it one of those tools then you can occasionally look back at stuff like did we already do that or didn't we um and then even within the code just like there's a lot of things like that that you can do I don't again another episode but if you start with the the basic good habits of being a developer then those will help those will help you moving forward that being said I'll say one I let you say something um the other thing though is if you are doing a POC sometimes this is a new application or new project so you may not have all those things in place that Rob said like J A bitbucket so what you might want to do is first start out by building a git repo build a local get repo and do it locally and make sure that you commit your code often so that you kind of have that uh running tally of what it is you're doing what's this change what's that change so when you're done even if it is just a PO but you decide to refactor it later you have all those notes you can put into the code AS comments or hopefully you wrote the code cleanly and the code is self-documenting but sometimes poc's are quick we're just trying to get it out there make sure it works and then come back and see if we can plug it into something bigger I agree I would just say that don't ever it should never be that it should always like just it's so easy to spin up a repository especially if you use GitHub it's going to automatically have you can use the the template kind of thing you will have a issue tracker you will have you know your Version Control you can do like you don't have to go do a bunch of branches or anything like that you can have a main trunk that you just are you're committing to along the way you got comments trust me I have built probably hundreds of demos and proof of Concepts and every one of them exists somewhere in some Version Control repository somewhere if nothing else so that you have a backup of where that stuff is and when particularly this is almost more important with proof of Concepts because you want to have that history of what did you do so if that thing grows you can always go back to something go hey I used to do that and go find it it is more important I would say starting out maybe even than it does further down the road almost as important as you checking in next time around we're going to wrap this this one up and we will be back next time obviously you guys are at the right place because you're at YouTube you get to see our glowing faces while we're talking to you come on back or if for some reason you can't stand our faces we won't take offense we get it we have to look at them all the time you can use a podcast and then it's pure audio and then all you have to do is just put up with our voices that being said go out there and have yourself a great day and we'll check in with you next time around [Music]
Transcript Segments
[Music]
button hello we are here we just hit
record so I'm going to say hello uh we
are talking about our topic for today
the initial thing I pitched and I'm sort
of like reading this as we go uh two
things I pitched well thing I pitched I
guess for now would
be
basically talking
about doing a a presentation of of some
basically like doing an assessment and
what are some of
the challenges that you were run to run
into um it would be
you know it is really it's out of order
from what we're doing I do think it's
part of the developer
Journey um but I think it's also going
from instead of starting early developer
Journey we're sort of jumping ahead to
later development journey and it's
mostly because it was on on my mind I
can't imagine why but uh it was you know
something that is near and dear to us
right now and I think
it's I really think that this is is one
of those things that
is in general a good conversation point
about communicating stuff because I
think we have even if you're not doing
like a full-blown assessment of
something you are often asked to like
you know talk about your app that you
did or maybe do a demo especially now in
the world of of uh agile and scrums and
Sprints you are asked on a regular basis
and maybe this is how we you know we
narrow it down a little bit more to a
developer but you are asked on basis to
demo your stuff and to walk through it
and how do you show this and how do
you address the needs of varying
audiences now this yeah an assessment
does get a little bit
more definitely into advanced developer
stuff because it's where you're like
okay you may be talking to a CEO or
something like that but there's there's
a lot of little pieces to this that I
think are useful for us to to talk
through which is why I pitched this out
I think we could come back around to it
later um
that was sort of what I was going with
this one um yeah and I was reading your
notes on that and
I I kind of feel that this is more an
advanced topic like we probably for the
assessment piece talk more about that
maybe 15 episodes in or 20 episodes in
at this point though if we want to kind
of stick to this theme a little bit
though we could get
into uh all right so we kind of talked
about about going from coder to
developer problem solving so the next
progression of that if we follow your
train of thought but bring it back to
the earlier part of their Journey let's
talk about you know all right so now
that you're solving problems now you're
working in an an environment where you
have to solve these problems how do you
go about researching how to solve that
problem how to put together like a proof
of concept and then how to pitch it to
whoever as your
solution I think that works I think
that's something and it's this is one of
those areas I think we'll come back to a
couple times from different points of
view so I like that so we'll work so
this episode uh which actually sort of
goes the second one that I wanted I was
thinking about that'll be that next
episode um so sort of basically start
with we got a problem all right how do
we actually show that we're solving that
problem before we solve the problem
effectively um you know how to which is
things like proof of Concepts and demos
and those kinds of things and then the
the second one I wanted to get into
anyways I think May dovetail well with
that is sort of a okay what happens when
you say hey here's the problem we're
going to solve and here's how we're
going to solve it and somebody's like no
no no no we're going to do it completely
differently and dealing with that
because sometimes it's a customer and
it's like customer's always right
sometimes it's somebody at work where
it's like okay this person's always
picking a different path
how do I deal with this you know it's
not it's not quite the poison pill
person where it's somebody that you're
just poisoned everything it's just they
are your Nemesis or something like that
where it's like you get into stuff and
everybody and people will especially
early on you're going to see that in a
company where you're you know this is
the right way to go this is like you've
been taught this is how we have to do it
and they go a different direction so
it's how do you work within that and you
know it's the kinds of things like
making sure that
you don't get yourself in a bad
situation because you've overreacted to
it and it's also and some of it's you
know keeping an open mind and some
things like that and and figure out
where you can learn and where you can
work within a maybe a very different
framework than what you're used to so
that actually is near and dear to my
heart because I'm dealing with that
right now I'm working on a program I
have a very tight
deadline um it's with creating
worksheets I'm having to create a new
worksheet on the fly right now we don't
have the backend data yet so I'm having
to mock all this and I come to find out
that all the data objects that we're
using to generate the reports are not
domain objects they are reusing the dtos
that we received from all of our API
calls and they were not reformed into a
structured format so I'm having to go
through hoops to build essentially the
domain object or the report from all
these different locations of
data yeah this is actually something
this was a this came in on the request
line from Timothy from Oshkosh Wisconsin
there was like brought it up and I was
like one I'm G to use your name and two
that's a really good idea because that
is something we run into and he
mentioned that yeah you may know
something about
that yeah I no I like that okay
so that's where we're going to go we're
going to start with like how do you show
You' solved your problem 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 on going too far
though I need to introduce myself my
name is Rob rhead one of the founders of
developing or 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 molash I'm another co-founder
of developer Nur I'm also the founder of
Invision QA where we help small midsize
businesses build custom software do
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 bit of our
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 uh we may have to
write it up we may have to design
something there may be uh a proof of
concept or a demo or something like that
and it's how far some of it is how far
do you go where do you find the where do
you draw line
between doing something and doing it for
real and this is often going to be a
situation will come up if you end up in
that side hustle industry where you're
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 no 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 Fisher cut bait
you're either accepting this project
we're moving on or we're not and you
also don't want to give too much away I
mean it'd be like a 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 it's like well
wait a minute that's not free advice
anymore you just stolen my my knowledge
and it's not quite to that level but it
is something along that ways 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 cancelled 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 the
problem here's the solution we get sort
of into it and it becomes not feasible
an example that I've run into lately is
uh 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 wasn't going to 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 you know 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 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 thing so I 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 like
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 General 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 th000
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 the
most positive say that okay this is the
growth curve of it if I've got 10
records it takes a microc if I've got a
100 records it takes three micros
seconds 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 you know curve or nice
progression line that I'm like oh cool I
know that I can do four million records
of this in x amount of time so the first
thing is with your solution when you're
doing that proof of concept the the
first thing what are you trying to prove
it's right 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 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 you're
keeping in your head or you're keeping
the the questions you want to answer is
where would this solution not be useful
and use those things to drive you know
your demo or your POC I'll throw it to
you because I've talked too much already
so what are your what are your thoughts
or maybe recommendation you
have yeah so to kind of build on that so
you I liked your idea you know where 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 tching onto that what 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 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 health care
maybe you can't use these apis because
they're not uh secure enough or you they
might be open and you might run into
some hippo violations or some socks
compliance issues
so don't just look at hey how do I solve
this problem with my with my you know
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 uh I had a very good case of
this and uh this was years ago Robin I
think this was even before I first met
you at uh the company we worked at was I
was approached with an idea of how can
we take this uh billing center um 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 uh 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 it 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 or web application that we can
solve that we can essentially eliminate
this
problem so we started out analyzing what
the business did you know what is the
problem you know what are the processes
in this particular case we were trying
to replicate what uh 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 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
cont concept to oops you're now live
you're now supporting something that's
not quite done uh 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 there live tomorrow and
you're like whoa I'm not ready this is
all mock data uh you know let's take a
step back you know how would you from
your perspective Rob how would you avoid
that situation you know what advice
could you give to our
viewers so that to answer that question
specifically um this is something that
we see on a on a
fairly I used to see it I think more
than we do now but as I'm thinking about
it now 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 it's 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 in
the particularly in the web application
world and and some of those even a
little bit desktop but definitely in the
in the SAS
World it makes a lot of sense because
you can put together a nice framework of
stuff a really focused solution 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 um like for example this is
one the 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 you know was like oh okay
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 uh or even
like a figma or something like that
where you have an images you have a
clickable demo you can make it look you
roughly approximate like user experience
and look and feel and all that kind of
good stuff
and it allows you to make this a selling
point as opposed to like a a point of
caution now before we you I don't want
to miss one of the things that Michael
brought up was the idea of you know 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 the
problems are not unique very often they
make 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
in a a specific Silo like healthcare it
has its 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 um 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 bons
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 it that
if nothing else when we were going
through all of those interviews and in
that long season or two there are a lot
of people we talked to that had very
Niche software uh services and products
that they did but they also had a large
number of customers so it makes sense in
the 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 that is you go out and
maybe you buy but you can customize or
you know it's buy and extend or buy and
customize
or maybe open source and customize
there's different levels of risk of cost
and of you know return of an 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 and a lot of times like 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 you know 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 a cross 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 the way you're
looking for and allow you to tack on to
that if you if you for a followup yeah
and a lot of those
situations now I know we touched on
agile and some more complicated things
we'll get into more depth of those along
the journey here but that's the idea the
problem as you addressed through you
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 but s you
know you could 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
uh could be by chance it could just be
uh happen stance but those are are good
things to happen because when you run
across that
um 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 that's you
know we got to learn to walk before we
run but sometimes you're running before
you're walk it's like whoops you're
already out the door gone and it's like
what just happened uh
but don't be afraid of those thrive on
those you know I love looking up new
technologies how does that work you know
it's like taking the TV apart and trying
to put it back together it may not
always work but you know 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 you know go to your boss and
say hey I heard you had this problem let
me take the stab at it go figure out how
to fix this and come up with a solution
for you let me do a
p 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 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 you know a
lot ear than you thought you were going
to or maybe a major headache and so you
run into those situations and we'll I
think this is something we will come
back to um and focus more in 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 worked with this
customer and we we had a solution and
we're like cool we're going to do this
and we came got further down the road
and we changed the solution they're like
wow we really need it this way 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 you know relationships and
things with within the data particular
with the existing data that we now had
to migrate out of and it was a very it
was a very painful tedious process to do
it so there's some things like that that
you want to be aware that you may be
biting off more than you chew you can
chew and particularly when you're 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 punt 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 you know subscribe wherever
you do your podcast you can check us out
on YouTube you can check us out on
developer.com you can shoot us an email
at info developer.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 and bonus information is there any
bonus material your thinking of yeah
actually so as you were kind of giving
your final thoughts just kind of jumped
into my mind as you're doing proof of
concept one of the other things to be
mindful and we all do is like oh great
let's go figure this out so you quickly
or maybe slowly figure out the solution
to the problem make sure you are a
little methodical with your
documentation your structure and your
notes as you go through the process of
your POC there's been many times I've
been bad about this I've seen a lot of
people where you get so excited you get
to that solution then you're like go
back and you try to maintain it and you
have spaghetti coat or you have no idea
where the heck you found that solution
or this one thing that is what you need
to do it as you go through the
process either keep track of your
browser history keep track of your bash
history but just take the time maybe
give yourself some checkpoints at the
beginning at least to document what
you're doing create a readme file but
just do something to keep track of
everything you're doing every so often
so when you do get to the end of the POC
if it happens to go live you have a way
of maintaining this not like oh my God
how the hell did I do this moment yeah
that's
where I've been in that couple the
refactoring can get to be pretty
nasty um the biggest Pro and this
becomes multiplied as an issue if you
have multiple Developers for example
I've got an app I was just looking
through not too long ago that we built
we built it quick we did a lot of stuff
we're making a lot of changes and I was
looking through the code and I was
really confused because we had three
copies of the same method the same
function was sitting there they're
basically almost back to back to back
and somewhere along the way we had
missed that hey we already have that so
code review would have caught that
theoretically um also there should be
some level of seeing that if you're
doing if you're really focusing on like
pull requests and and committing code
again it does go back to some level of
code review but these are kind of things
as you're building them try to you know
keep some notes use the docent
particularly if you've got built-in
documentation tools like Java do or
something like that is just you should
be in the habit of doing that kind of
documentation at the very least like I
do I do like daily standups if you've
got a little status or something that
you can go see what was your standups
then maybe you can see what was you know
done along the way or use like if you're
using Trello or jro or you name it one
of those tools then you can occasionally
look back at stuff like did we already
do that or didn't we um and then even
within the code just like there's a lot
of things like that that you can do I
don't again another
episode but if you start with the the
basic good habits of being a developer
then those will help those will help you
moving
forward that being said I'll say one I
let you say something um the other thing
though is if you are doing a POC
sometimes this is a new application or
new project so you may not have all
those things in place that Rob said like
J A bitbucket so what you might want to
do is first start out by building a git
repo build a local get repo and do it
locally and make sure that you commit
your code often so that you kind of have
that uh running tally of what it is
you're doing what's this change what's
that change so when you're done even if
it is just a PO but you decide to
refactor it later you have all those
notes you can put into the code AS
comments or hopefully you wrote the code
cleanly and the code is self-documenting
but sometimes poc's are quick we're just
trying to get it out there make sure it
works and then come back and see if we
can plug it into something bigger I
agree I would just say that don't ever
it should never be that it should always
like just it's so easy to spin up a
repository especially if you use GitHub
it's going to automatically have you can
use the the template kind of thing you
will have a issue tracker you will have
you know your Version Control you can do
like you don't have to go do a bunch of
branches or anything like that you can
have a main trunk that you just are
you're committing to along the way you
got comments trust me I have
built probably hundreds of demos and
proof of Concepts and every one of them
exists somewhere in some Version Control
repository somewhere if nothing else so
that you have a backup of where that
stuff is and when particularly this is
almost more important with proof of
Concepts because you want to have that
history of what did you do so if that
thing grows you can always go back to
something go hey I used to do that and
go find it it is more important I would
say starting out maybe even than it does
further down the road almost as
important as you checking in next time
around we're going to wrap this this one
up and we will be back next time
obviously you guys are at the right
place because you're at YouTube you get
to see our glowing faces while we're
talking to you come on back or if for
some reason you can't stand our faces we
won't take offense we get it we have to
look at them all the time you can use a
podcast and then it's pure audio and
then all you have to do is just put up
with our voices that being said go out
there and have yourself a great day and
we'll check in with you next time around
[Music]