304. Why "It Depends" is a Developer's Most Important Phrase

Why do senior developers always say "it depends"? Why can't they just answer the question? Why do we have all of these choices in software development? Why can't we just agree on the best solution? Doesn't AI make these decisions easier? Should we care? 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

If you asked a seasoned developer for specific advice, you have probably heard the phrase it depends. If you've listened to more than one dev questions episode, you've probably heard me say that as well. But why is that phrase so important? Because personally, I would say that it's one of the most important phrases a developer can utter. And if you don't understand why, you could be in real trouble. So let's talk about why it depends is so valuable in today's episode of DevQuestions.

SPEAKER_00 0:38

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:42

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about why the phrase it depends is so vitally important. Clear answers are important, and being vague is infuriating. Yet it feels like some developers will never give you a straight answer to a question. So let's get specific. I'm going to give you a simple scenario, and then we're going to come up with how to answer that or how to respond to that. So you've come to me and you've asked me how to best create a simple data entry form. What's the best technology to use and the best database type to store that data in? Now that's a really simple scenario. In fact, it's probably the most simple scenario in software development. You create a form, you save data in the database. That's like the basics of practically every application, and it's something we've done hundreds of thousands of times over the years. So here's what I would need to evaluate in order to answer the question. I can't just say, well, I've done this 100,000 times, therefore, this is the answer. Because I've done this 100,000 times plus, but I've done it differently a lot. So here are the things I'll need to evaluate in order to come up with a solution for you. We're going to number these. Number one, I'm going to ask you some questions. So, number one, what current technology are you using? So, what languages are you using? What tools are you using? What current technology are you using? Because that's important. If you are currently using.NET framework and you're using C sharp or VB.NET, well, that changes how I respond versus if you say I'm all on the front end with JavaScript. Okay, the language you're using right now matters. The tools you are using matter. If I tell you, okay, you're currently using .NET with Visual Studio 2026 and C sharp, and I say, okay, the best way to do an input form is to use, I don't know, um, COBOL, because that's a great language. Um, it's been used, it's still being used a lot. Well, you're gonna have to have a new IDE, you're gonna have to have a new set of processes, a new deployment pipeline, a new way of deploying code. Like that would change everything, right? So, but yeah, if you're using COBOL, I shouldn't be telling you, well, then install Visuals to 2026 and install C sharp and work with new Git packages and all no, I probably shouldn't do that. So, what current technology are you using is an important first question. That's only number one. Number two, will this have to integrate with existing systems? We talked about if you're currently on.NET Framework. Well, if you're on.NET Framework but this doesn't have to integrate with any of the current systems, I might say, well, then build a.NET 10 app. It's still C sharp and the C sharp code will be really close to the same, but yet you'll have a modern, fast, performant system in place for at least this application, this piece of the application. But if you have to integrate with an existing system and you're currently using old school ASP forms, well, then you might create another ASP form. Or you might create a PHP page if you're using PHP. Like if you're gonna exist work within an existing system, you have to think about that as a limitation. Not because you couldn't do something else, but because by doing something else, you're gonna hurt yourself in the long run. Because part of the code will be over here, part of the code will be over there. And that's one choice. If you make 10 of those choices throughout the next couple of years, all of a sudden your maintenance is gonna be horrific. So integrating the current systems, it's important to know how to do that well. That's number two. Number three, do you already have a database in use? Maybe you're a huge fan of MongoDB. Maybe you love it, but we're already using SQLite. Well, you probably shouldn't use MongoDB in this situation because it's one more database to support, it's one more database to secure, it's one more database to backup and to test. You are testing your backups, right? Um, it's one more thing to do. Well, if you already have a database and use, it's probably better to use that existing database structure, that database system, or even just that database type. Maybe you're using Microsoft SQL Server and you don't want to use a different database, but you could use a different server, but you can use another database on the SQL Server. That might be okay. Or it might be that no, you want to integrate your data, your table, right into the current database so that it's easier to link to other existing data in the system. Those kind of questions are gonna inform how you choose the right database. That's number three. Number four, is this a standalone project, or do you expect it to grow over time? Meaning, are we gonna build a little application? It's just gonna be just this little application, which Pro Tip almost never is. Um, or do you expect this to grow over time? Meaning, does this start off as just a little data entry thing, but does it grow into this larger system we have to maintain? That's important to know because it's important to know how to grow this. Maybe if it's a little standalone application, you don't have to put a lot of thought into the code. You don't have to have a lot of uh work going into making sure it's as maintainable as it otherwise might be because it's so simple. You just throw some stuff together and put it in a SQL like database, even though you're using SQL, because that's not a big deal for this one little standalone application. But if it's gonna grow over time, that might become a problem. And data migrations are hard. You don't want to do that if you don't have to. And then code migrations are hard. And taking code that's not well written and turning it into good performant code that's well written can be hard as well, especially integrate into a new pattern of doing things. That's number four. Number five, what's the deadline for this project? Because that's gonna be a big deal difference. If you tell me that you want this little app up and running, and yes, we have existing tools and technology, we've got to integrate current systems, we have a current database type we want to use, it is gonna grow over time. But the deadline is tomorrow, that changes how things get built. Now, we're talking a really small application here, but if you're talking about an application that would normally take you two weeks to build, and your boss says you have two days, that could change what you do. It changes the type of code you write. You might write code a whole lot faster and a whole lot messier. It's not as maybe performant as you'd like. You want to do as best as you can, but it is what it is. And it's not necessarily as uh clean as you would like, so it's gonna be a little bit harder to maintain. But you know what? It is what it is because you got to get that in going. Or you might find out you've got a month to do this, so let's do this right. So, what the deadline is, is number five. Number six, are you planning on migrating your existing application to a new language or database? So you have existing code, right? And if you do, maybe it's in, let's say,.NET framework. But if you're planning to move your.NET framework code over to.NET 10, and I would encourage you to do that. Um, if you're doing that, well, even though I want to integrate the current current systems, and even though writing it a different language or in.NET 10 now might be a bit of a pain point, that might be a pain point that goes away rather soon. Therefore, it's better to write it in.NET 10 than to write it in framework and have to migrate one more piece of code. So that makes a difference as well. That's number six. Number seven, what's the skill of the current team? I worked on a project where we were doing an Angular app. And I knew that the team was not big on JavaScript, but yet I didn't want to be the only person that could maintain our front-end application. So when I built that JavaScript, I intentionally didn't use all the Angular features that I could have. And the reason why is because I wanted to keep the code as simple as possible. That changed what I did. That changed what parts of even Angular I used. So the skill of your team is important and it will change what decisions you make about how you write your code, what type of application you build, whether or not you go outside of the norm, etc. Number eight, what tools do you already have in place that you can take advantage of? This might be libraries. If you already have a whole bunch of libraries in place that work with your in-house email system and authentication and all the rest for.NET, it might be easier to use those than it would be to re-roll everything yourself. So, what tools do you have already in place that you can take advantage of to move faster compared to doing it all new? That's number eight. Number nine, where do you want it deployed? People often forget this, but where you want to deploy is going to change how you build your application. If you want it deployed internally, maybe an internal server, well, you can write a uh a web app that is an internal-only app that's less secure, maybe, than you might otherwise do, but it's an internal app, maybe it's okay. Or you might say, you know what, we could use a deployment system to deploy a desktop app to everyone's computer, because desktop apps are often faster and have less quirks to them versus web apps. So that might work. But if you have external customers, that might not work. Or you might even say, and this is crazy to think about, we're gonna deploy a command line application because it's a developer application, and our developers are all in-house and they know how to use CLIs. Where you want it deployed matters. Who it's gonna be deployed to matters. So understanding that is number nine. Number 10, where's it gonna be hosted? You see, if you're hosting it in-house, directly connected to your Active Directory or entra system, that might be different than if you're hosting it on a third-party VPS server or somewhere else. Where you host it's gonna matter because it's gonna change how you build your application. Maybe you want to do a .NET application, but your host doesn't support.NET applications. Well, maybe it's PHP for you then. You know, it that's gonna change how you do things. Number 11, what are the goals of the organization? So, what is the organization thinking about how this fits into the overall goals of the application? Is this a critical piece of the application of the organization's goals, or is this just a side project to solve a little problem? Because if you know what the goals of the application are or of the organization are, if you know where it's going, you might be able to predict some of the things that might or might not impact your application. Maybe people keep telling you it's a small application, it's just a little tiny thing, but you know the goals of the organization are leaning towards making this a bigger application than it already is. That's important to know. Number 12, are there any other applications that might use this system? So we're gonna build this little form, it's gonna input data, but might we want to drop this in somewhere else? Maybe we want to have this right now, it's a standalone application, but maybe we want to drop it into our existing web application and have that be like a sub page that that takes that same data entry in. Well, then you probably shouldn't use a desktop app to build this application, right? So those are 12 questions. They're not they're not the 12 questions you must ask. These are just ones I thought of off the top of my head. These are not all of them. And every situation will be different because the answers to some questions will spark other questions. And you'll go on and you'll ask dozens of questions to get the right answer. This is why you want to say it depends, because it really does depend. All of these questions have different answers depending on the situation. And because of those answers, that'll open up new questions that will also have different answers. So once you get even just these 12 answers, you're gonna have a better idea of the scope and requirements of the project. Now, again, you might have to ask more, you might have to ask different questions, but you should have a better idea of the scope and requirements of the project. It's then that you can start evaluating what options best fit your specific scenario. That's why the right choice for you might be an older technology, or it might be a different language, or using a different database type that you've used for previous projects. And ultimately, this is why software developers create so many choices. Choice, hear me on this. Choice is vital to making the best decision for your specific situation. There is no one right answer. If there was, well, then we'd all be the same. And we're definitely not all the same. So if you want to properly evaluate any decision, you need to talk about making the best decision for your specific situation. That means asking a lot of questions, getting a lot of information before you even start to talk about potential solutions. So if you want to properly evaluate any decision you make, you should be absolutely starting with it depends. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 15:29

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