319. How To Properly Evaluate a Technology

How do I properly evaluate a technology? How do I know if using AI is good or not? What is the right programming language? What is the best JavaScript framework? These are the questions we will answer in today's episode of DevQuestions.

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

The most used phrase of a senior software developer should be it depends. That's because every situation is different, and a solution to any problem needs to take a number of situation-specific variables into account. That's why there are so many languages, frameworks, and ways of doing things in software development. But what we don't talk about as much is how to properly evaluate an option or a technology. In today's episode of DevQuestions, we're going to discuss how to properly evaluate your options without letting enthusiasm, pessimism, ignorance, or inertia get in the way. Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about properly evaluating your options. And let's start by looking at the four major categories of people. Number one is the enthusiast. So this is a person who knows all the new features of a thing, how it's better, how it's improvement, what's changed. They are very enthusiastic about this new thing. Now, you can kind of overlay that on an ad, right? So if if you heard the maybe the head of an LLM talk about their new thing, it's going to sound an awful lot like an enthusiast. That's not to say that enthusiasts are just people spouting ads. They're not. But what they've done is they have looked at all these new things and they're excited for it. That's the enthusiast. Number two is the pessimist. So this is the person who's going to spot all the problems. And they might sound a little depressed, right? So they they talk about, oh, this new technology, yeah, that that thing's got a whole bunch of security holes, probably. It's probably not written real well. You know what? It's gonna be the end of civilizations. We know it. Here's all the downsides why it's going to fail. Now, again, this person isn't necessarily wrong. They're going to spot the issues, the problems, the downsides with this thing, whatever this new thing is. Number three is the ignorer. This is the person who hasn't really looked into it. You know what, not really passionate either way. Give it time. You know, it's the person that, you know, yeah, I heard it's out there, but that's about it. I haven't looked into it. I kind of just left it off the radar. I'm just kind of ignoring it. And this person is in their own way right as well, because they're not just chasing down the latest trend. They're not always disrupting everything. They're kind of picking and choosing when and kind of waiting for more of the tried and true over the bleeding edge. And number four type of personality is the unmoving person. This is the person who's stuck in inertia. They're stuck in the rut, where the way they've done things is the way they're going to continue to do things because it works. If it doesn't, you know, if it's not broken, then don't fix it, right? That's the type of person that this person is. Um, the old ways are the best ways. You know, these new things, they're they're wrong for these reasons. The old way was the best way of doing things. You know what? We should still be programming in whatever language. I don't want to offend anybody, but you know, the the older languages or the older frameworks or this way was best. And, you know, they're not wrong either because change is costly. And so there is something to be said for not just changing all the time. So here's the truth: all four people or personality groups are correct. They just aren't fully correct. You need all four to come together to evaluate a new option. Too often, people are afraid to face the other side of an argument, where they either like it or hate it, and they want to find things that affirm that rather than confronting the fact that there is another side. And that fear can really hold you back. If you cannot confidently and honestly face the other side of an argument, then you don't have a strong argument. What you have is just the thing that you like. And you can like things, but it doesn't mean that you're making an honest argument. So let's be clear: if you cannot properly and fully fill out all four roles for any decision you make, you aren't making good decisions. You're just hoping for a happy accident. People often say they're evaluating the pros and cons, but they're often lying to themselves. The most common situation is the person is fully in one category and kind of pretending you're making a half effort in the others. Let's go through a relevant example because this has come up a lot recently, and that is AI. Everyone has an opinion on AI. I've had conversations with each of the four categories of people about AI. So let's start with each category and what it might look like when it comes to AI, and then we'll narrow it down a bit to be just AI for developers because AI is such a broad category. So let's talk about the enthusiast. You know, AI makes me write code faster. I get work done, I get more work done, I get to the market quicker, I do more with less. This is the enthusiast. They they see all the benefits of being able to have the code written for you where you just say, I want this, and it pops out the other end. It can get a lot of work done fast. We see a lot of this. And you know what? There is something said for the fact that, yes, it can make you a faster developer. It can help you write code better, you can get more work done with AI. And by the way, pause right here. If you are against AI or frustrated AI, which I can I can get, but if you can't say honestly that there's positives to it, then again, you're you're just looking at one side. You've got to look at both sides. Now, that doesn't mean that you think that these are all gonna be the reason to do it. You just need to acknowledge the fact that there are reasons why it exists. There's a reason why it's positive. Okay, so that's the enthusiast. It writes code faster, it gets more work done, you can get to market quicker, you can do more with less. It can empower companies in a way that smaller businesses can actually get into the market and do custom things as opposed to just buying off the shelf and being limited. So there's a lot of reasons you can list, and I've only listed a few, but why you can be enthusiastic about AI? Let's look at the pessimist. Well, AI coding can introduce more bugs because you're moving faster, and so you miss things. And AI doesn't always write the correct code. It writes it correct a lot of the time, but not all the time. And so it can introduce some significant bugs. Also, you lose institutional knowledge about the code, meaning when the AI writes it and you're just reviewing it, well, then you're not really baked into why the decisions were made. So you're no longer the go-to person for the code. You might say, well, AI is. Well, yeah, but AI doesn't remember, right? Where humans, we've gotten used to this idea that there's a senior developer who knows where all the bodies are buried, right? They they know why we made these decisions and why we made these compromises. And you don't know that as much. So you also don't have as good an understanding about your security and performance. And AI is not great at that usually. So that's gonna be a weak point for your company. Again, if you are an AI enthusiast and going, yep, yep, yep, well, here's the thing. You need an, I'm sorry, AI, a negative person towards AI. And you're going, yes, yes, yes. Well, but remember, there's a positive as well. Okay, we have to understand both sides. So if you're an enthusiast and go, you know, those are those are not problems, well, then you're missing out. There are problems. You have to acknowledge it. Um, this is one of the reasons why I did the AI hurts everything series. It wasn't just to be a pessimist, which is more of what those videos are about, is the pessimistic side, not because I'm a pessimist, but because I was kind of fearful that people weren't looking at that side of things, where they were looking at the enthusiast side, but not the pessimist side. And yes, you have to look at both of those. But again, there's two more to go through. Number three, the ignorer. So, you know, if if you're looking at AI and saying, hey, I want to look at from the role of the ignorer, well, I'm gonna look at this and go, you know what? We need to wait for some dust to settle right now. Because the way to use AI today is not the way we used AI a month ago, which is not the way we used AI two months ago. I mean, are you doing loops right now? Are you doing uh agents? Are you doing skills? Are you doing MCP? Are you doing like all these things are changing and constantly evolving? And the problem is the way you do things today won't work the same in a month. The prompt you write today that's that's perfectly customized for that version of the LM won't work as well next month. So, yeah, there's a little bit of thinking about, you know what, maybe you should wait for the dust, thus, the dust to settle a bit on some of this. Maybe we should think about what we do and don't do when it comes to AI because of how fluid it is. Maybe we skip some of the churn of that new technology and we wait for the evidence to mount over what is the right way of doing things. Maybe we let other people kind of get ahead and kind of learn the ropes, figure it all out, and then we come along and build on their shoulders instead of trying to replicate them. So the ignorer has some good points as well, but you know what? There's a lot of churn going on, and it's being expensive for us to jump in right now. It's even more expensive because of the cost of the credits. So if we ignore and don't just try and learn as we go and reinvent the wheel like everybody else is doing, we can just learn from others' experiences and not have to pay for them. And number four, the unmoving. Still doing things the way we used to, you know, that that could be something that is beneficial. Because maybe if we continue to do things the way we used to, if the whole market changes, but it doesn't get better. So we're seeing things like there's more security flaws and there's worse performance, and you know, companies are struggling, and companies are out of business because of the push to go fast. Well, if you're unmoving, you're still doing the same way you used to do things, you might actually move ahead of the pack because now you're the reliable one. And this allows you to say, you know what? Maybe we do things the way we've done things because we've proven that it works. And it's if something that, you know, it wasn't broken. So let's not try and meddle with it. Let's keep our same processes and technologies. Now, again, remember, we're not looking at just one of those people. We want to look at all four then. So the reality is that too many people could only passionately argue for one of those categories. The rest they only give passing lip service to. So if you're making a decision about AI for development, you should be able to answer the following questions. Number one, what benefits will this actually add to our team and process? I want you to stop right there. We're not talking about what are the talking points. We're not talking about what are the cool things about AI. Nope. We're talking about what benefits will this actually add to our team or process? What's the real concrete things that's going to add? And you're going to find some. You probably should. If you don't, stop right there because you're done, right? But number two, what downsides is this going to add to our team or process? And again, you should know specifically for your environment. Uh, really quickly, one you can add is there's a cost, right? Nothing's free. And AI is not cheap and it's not getting cheaper. It's getting more expensive. So that's one downside, but that's not the only downside. But if you have to look at how is it being used in the industry and what are the results we're seeing, and go, oh, there's some other downsides. That's why I did the video on how it hurts software development, because there are some impacts that people aren't addressing. So, what are the downsides to this? We have the benefits listed. Now do we have the downsides to kind of put on that scale to say this is starting to weigh more or less than the other? Now we're not done yet, though, because number three, has this been tested or are we rushing in? So have we are we implementing a tested thing where people have said this is how you do things? Or is it this is how you do things this week, and we're gonna have to change a process over and over again? And do we even have the bandwidth to change right now? If you're in the middle of a process, you're middle of a system, upgrading just isn't the right time. You know, doing things differently halfway through a major project isn't the right time. A very simple example of this is I use recording software. I'm using recording software right now to record myself. Well, I get updates all the time. Unfortunately, it's faster and faster now, where it will say, hey, there's a new update. There's a new update. Guess what I don't do? I don't upgrade right away. I don't make changes until I know I have a day or two to figure out the problems. Because if I say every time I see an upgrade, yeah, go ahead and do that, and then jump right into recording. I've had times where I've done that and then I have no sound because I change the default uh capture, or the video looks weird, or I have a sync issue. So you want to make sure that you are using something that's been tested and that you have the bandwidth to do the change right now. That's number three. Number four, does this new system improve our process significantly enough? Not does it make an improvement, is it significant enough? It has to overcome that inertia. You have a process. In theory, it's working. In theory, you're putting software out there. So is this change going to make your process significantly better? Okay. Is this going to provide enough gain for the pain that's going to cause? Because any new change is going to cause pain. So you should know the answers to all these questions before you make an informed decision. Otherwise, it's not an informed decision, it's a wishful guess. So once you've honestly evaluated all four possibilities, can you, or all four positions, I guess you'd say, um, you can make an informed decision about what to do, but you aren't done. Then you need to evaluate if you thought what was going to be true actually came true, right? So you can't stop it, we made a decision. You have to wait a month, two months, three months down the road, and then look back at those four questions that you answered and say, were we right about these answers? Did the good things come true? Did the bad things happen at the level we expected them to? Did this benefit us much more than what we were currently going through? You know, answering these questions later and seeing, were we correct in our assumptions? Because there are assumptions. So are you only experiencing the downsides you expected? You know, are you not getting the benefits? Like you need to understand how to evaluate and see, you know, just because you're doing it now doesn't mean you should keep doing it. Maybe you look at it and go, oops, we were wrong. Okay? So this is important to understand. We often allow our bias to cloud our judgment, but that way leads to poor decisions and guesses. Instead, you need to actively push against your bias to get to a point where you can make well-informed, honest evaluations that can also adjust over time. This is one of the where areas where I was very successful as a consultant because of the fact that I could say, hey, we were wrong. Hey, you know what? We we put that in, it didn't work the way you expect it to. Let's make an adjustment. Or here's what I've learned over time, the positives and the negatives. And that really can have a positive impact on a department because you're coming in and showing the full spectrum. Because you know what, if you're super enthusiastic about something and you say, you know what, this new widget is going to do amazing things. Here's all the benefits it can do. And you forget to evaluate the rest of the stuff and you implement it, the rest of stuff's gonna show up. It's not going to be something where you put it in all of a sudden everything's sunshine and roses because you said all these new positive things. The negative things come along, whether you want them to or not. So if you're informed and you inform people about that, they at least know up front, this is what we're expecting for the downsides. This is what we're expecting for the implementation timeframe. This is how we expect it's going to negatively affect our process for a while. These things are all important to understand so you can have a proper viewpoint on what this change might look like. Because right now, there are a lot of teams that have just dove right in, or dove in? I don't think that's the right word. They dived right in. There you go. Um, they dive right into AI. And they they put AI in the, they told our teams, hey, make AI right while your code from now on. I want you to be a project manager. They kind of just dove right into the whole process without doing the fully evaluation. And you know what? They're finding out the negatives. I'm not saying that AI is bad for your business, but you have to make sure that you fully evaluate it to say, hey, you know what? Here's the downsides. Because there are some significant downsides that, if you aren't prepared for, will really cause problems and get people frustrated. And you might even lose a good thing because they didn't expect the downsides. Where a good thing that did have more positives and negatives, but because those negatives were surprises, it really ends up tainting the whole process and you lose the good thing. So make sure to be an honest evaluator of your options. Don't just say it depends, but then not really be honest about the positives and negatives, the way to evaluate if it's if you should move or not. Um, all these things are really important. Okay. So I would encourage you to make sure you cover all four categories. Make sure you answer those questions and make sure that you understand your decision before you just make it. All right. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 20:25

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 IamtimCorey.com and enroll in a course.