Latest / DevQuestions with Tim Corey / 087 What Makes A Good Software Application?

Transcript

087 What Makes A Good Software Application? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: What makes a good software application?
• 0:28
  SPEAKER_01: What provides the application with the right stuff to make it a good software application as opposed to an okay software application?
• 0:38
  SPEAKER_01: Let's talk about that in today's episode of Dev Questions.
• 0:42
  SPEAKER_01: Now, I think there's really three important ingredients to making a good software application.
• 0:50
  SPEAKER_01: And I encourage you to write these down, think these through with every single application you build.
• 0:56
  SPEAKER_01: Because there are often things that slip, that get muddled and confused, and with that you start to lose that good software application in the name of doing good.
• 1:09
  SPEAKER_01: Okay, so let's talk about these three things.
• 1:11
  SPEAKER_01: Number one, clarity of purpose.
• 1:15
  SPEAKER_01: Clarity of purpose is important for a good software application.
• 1:19
  SPEAKER_01: If you can't define it, the purpose that is, if you can't define it, your users just won't understand it.
• 1:27
  SPEAKER_01: So you have to be very clear what is the purpose of your application.
• 1:32
  SPEAKER_01: And that purpose needs to be clear, it needs to be focused, it needs to be on point.
• 1:38
  SPEAKER_01: You can't just say, I'm building an application to you know make a game.
• 1:45
  SPEAKER_01: That that's not clarity of purpose.
• 1:48
  SPEAKER_01: That is so vague as to be not intelligible, not understandable, not really a good definition at all.
• 1:56
  SPEAKER_01: So if you can't define what your application does very clearly and very pointedly, then your users won't understand it either.
• 2:05
  SPEAKER_01: That also means if you're not clear with what the purpose of your application is, then you're vulnerable to scope creep, to confusion, to complexity, and to delays.
• 2:18
  SPEAKER_01: Let's talk that through.
• 2:20
  SPEAKER_01: If you're not sure what the exact purpose of your application is, then that additional feature that sounds great could be valuable.
• 2:31
  SPEAKER_01: And so you add that on.
• 2:33
  SPEAKER_01: Now your scope creep your scope is creeping, and what your application does is growing because that was a good thing, right?
• 2:41
  SPEAKER_01: But maybe it wasn't right on point for why you're building your application.
• 2:46
  SPEAKER_01: But if you don't know that, you add it in.
• 3:01
  SPEAKER_01: And so whether you do this way or that way, it kind of depends.
• 3:06
  SPEAKER_01: For example, you say, I want to make an accounting app, that's not clear at all.
• 3:12
  SPEAKER_01: So when it comes down to decisions like should it be web-based or desktop-based?
• 3:18
  SPEAKER_01: Mobile app, or should it be um just you know on the server?
• 3:24
  SPEAKER_01: Those questions you can't really answer is you don't have enough clarity of purpose.
• 3:31
  SPEAKER_01: So with that also comes a complexity, the idea that you're adding lots of stuff because it's all good stuff, it might be needed, you're not sure if it helps or not, and it adds that complexity.
• 3:44
  SPEAKER_01: And with all those things, the scope, creep, the confusion, the complexity, all those things add delays to your project, which means your project deadline gets we go past that, we extend the project, we delay the project, we you know miss deadlines over and over again because you don't have the clarity of purpose as to exactly what your application is designed to do and do really well.
• 4:13
  SPEAKER_01: So that's the first thing that determines a good software application is clarity of purpose.
• 4:19
  SPEAKER_01: Now, here's an example of that.
• 4:21
  SPEAKER_01: Think of a Swiss Army knife.
• 4:25
  SPEAKER_01: What is the clarity of purpose behind that tool?
• 4:29
  SPEAKER_01: Well, it's utility, it's the idea that we could do anything.
• 4:34
  SPEAKER_01: That's not really clear purpose.
• 4:36
  SPEAKER_01: So when it comes to that Swiss Army knife, it's got a little bit of everything.
• 4:41
  SPEAKER_01: In fact, there's major, massive, huge Swiss Army knives with tons of stuff in them.
• 4:47
  SPEAKER_01: Now compare that with a screwdriver.
• 4:50
  SPEAKER_01: A screwdriver only does one thing, but I tell you what, it's very, very clear as to what it does.
• 4:56
  SPEAKER_01: And when you need a screwdriver, if you have the option between have using a screwdriver and a Swiss Army knife, you're gonna use that dedicated screwdriver because that dedicated screwdriver does one thing really well.
• 5:10
  SPEAKER_01: And you know what?
• 5:11
  SPEAKER_01: It's probably a whole lot faster to build that screwdriver, and it's a whole lot cheaper to buy that screwdriver because it's it's simple, it's clear, its purpose is very defined, very limited.
• 5:25
  SPEAKER_01: The scope creep didn't happen.
• 5:26
  SPEAKER_01: We didn't add one more tool to it.
• 5:28
  SPEAKER_01: It's not confusing as to how to use it or confusing as to how to build it.
• 5:33
  SPEAKER_01: It's not complex, and I tell you what, they're fast to make.
• 5:38
  SPEAKER_01: So that's the difference here.
• 5:40
  SPEAKER_01: I'm not saying that Swiss Army knives are bad, but I'm saying is when you're building your software application, you want to build a screwdriver.
• 5:48
  SPEAKER_01: You don't want to build a Swiss Army knife.
• 5:51
  SPEAKER_01: Okay, have that clarity of purpose.
• 5:54
  SPEAKER_01: Now, number two in what makes a good software application is that it solves the right problem.
• 6:03
  SPEAKER_01: This is a mistake that people often do is you solve a problem that that no one has, and so it helps no one.
• 6:14
  SPEAKER_01: So you're not solving the right problem.
• 6:16
  SPEAKER_01: You're solving a problem or what appears to be a problem, but you're not solving the right problem.
• 6:21
  SPEAKER_01: In code, think of it this way: when you're going to optimize your code, you're saying, hey, I need to make my code faster.
• 6:28
  SPEAKER_01: Well, if you just go through your code randomly and try to make your code faster, you may shave off two nanoseconds off of a method that's called once.
• 6:40
  SPEAKER_01: Who cares?
• 6:42
  SPEAKER_01: Who cares at all?
• 6:44
  SPEAKER_01: Because you waste that time, maybe a day, working on optimizing that one little piece that had no real value add by doing that optimization when you've got a connection to the database that takes five seconds to happen.
• 6:59
  SPEAKER_01: You know, if you did a little bit of work on that, you could have saved 4.9 seconds, okay?
• 7:05
  SPEAKER_01: And maybe you know, per iteration and that you do that a thousand times per session.
• 7:10
  SPEAKER_01: Well, that's a whole lot different than one time an optimization of two nanoseconds.
• 7:15
  SPEAKER_01: Okay, so you need to solve the right problem.
• 7:19
  SPEAKER_01: The example here is if you are a minivan manufacturer and you say, you know what, we've our minivans now go even faster.
• 7:29
  SPEAKER_01: Who cares?
• 7:30
  SPEAKER_01: Okay, who cares that instead of going 110 miles an hour, it can go 120 miles an hour?
• 7:37
  SPEAKER_01: Okay, most moms or dads aren't driving their minivan 110 miles an hour, okay, at least not often.
• 7:43
  SPEAKER_01: Um, we all have speed limits, most of us have speed limits, and they're probably going a lot slower than that.
• 7:49
  SPEAKER_01: So adding an extra 10 miles per hour to the top end of a minivan doesn't really seem like you're solving the right problem.
• 7:56
  SPEAKER_01: Instead, maybe you spend that time on putting automatic doors in so that the parents who are dropping off kids at uh at school or who are picking up kids, and you know, the idea that they can just push a button and the door opens, the kids can all pile in, they can push the door and it door closes properly.
• 8:14
  SPEAKER_01: That's a whole lot better problem to solve.
• 8:18
  SPEAKER_01: So solving the right problem makes your application better.
• 8:23
  SPEAKER_01: So when you're looking at the problems to solve, make sure that you've identified the right problem.
• 8:29
  SPEAKER_01: That means you need to talk to the users, you need to know exactly what the problems are from the user's perspective, not what you assume they are, not what your boss assumes they are, not what even your company assumes they are.
• 8:46
  SPEAKER_01: You need to talk to the actual users and hopefully quite a few of them to really understand what the problems are.
• 8:54
  SPEAKER_01: Otherwise, you will solve the wrong problem.
• 8:57
  SPEAKER_01: And if you solve the wrong problem, then your software is not going to be perceived as good software because it may solve that wrong problem excellently.
• 9:11
  SPEAKER_01: Doesn't matter.
• 9:12
  SPEAKER_01: You know, a minivan that used to go 110 miles an hour, it could go 210 miles an hour.
• 9:17
  SPEAKER_01: You've solved a huge problem.
• 9:20
  SPEAKER_01: Who cares?
• 9:21
  SPEAKER_01: You solved the wrong problem.
• 9:23
  SPEAKER_01: Okay, solve better problems, have better software.
• 9:27
  SPEAKER_01: Now, number three is improve the user's life.
• 9:33
  SPEAKER_01: Your software to be considered good software by the people actually using it, needs to make some kind of improvement in the user's life.
• 9:45
  SPEAKER_01: A here's a bad example, a fancier user interface.
• 9:49
  SPEAKER_01: Okay, so it's you know it's modern instead of the battleship gray, ugly form, it's now this really modern um metro look or you know, the flat look, whatever look you go for, and you've got this really great design, but that fancy UI takes longer to navigate, then you just hurt the user, you didn't make their life better.
• 10:12
  SPEAKER_01: I'd say I've seen this over and over with fancy software applications because there are certain jobs where people just have to input information.
• 10:23
  SPEAKER_01: They input a lot of information, and so they want to go fast, very fast.
• 10:29
  SPEAKER_01: And they have these ugly applications that look horrible, they're just barely above Excel in a window applications.
• 10:40
  SPEAKER_01: But they the users love them because of how fast they can go through and enter the information.
• 10:46
  SPEAKER_01: If you replace those informate those applications with fancier applications to have three and four forms that have one ugly page with data in it, that makes the user slower, which means you've hurt their productivity, which means you've hurt their job, which means you have not improved their life, you've hurt their quality of life.
• 11:08
  SPEAKER_01: How do I know this?
• 11:09
  SPEAKER_01: Because I've done this.
• 11:10
  SPEAKER_01: I have done this, I have created better applications in my mind.
• 11:15
  SPEAKER_01: I when I was um a new consultant, I created a great application, I thought, that really elevated the process and made sure there was better checks on the data and made sure that it properly went through the process and it walked the user through filling out information.
• 11:33
  SPEAKER_01: And I gave it to the user and they said, This is crap.
• 11:37
  SPEAKER_01: This is horrible.
• 11:38
  SPEAKER_01: We don't want to use it, take it away, we'll use the old stuff.
• 11:42
  SPEAKER_01: And I couldn't figure out why until I talked to the users and they said, Well, watch what I do.
• 11:49
  SPEAKER_01: And they just put their head down and just typed.
• 11:52
  SPEAKER_01: And they never even looked up, they never used their mouse.
• 11:55
  SPEAKER_01: I was using mouse all the time to click next, next, next.
• 11:58
  SPEAKER_01: They never used the mouse, they just you know, type tab, type tab, type tab, fill out the information, hit enter, then type tab all the way through, hit enter again, and they fill out two, three, four, five, six pages of information without ever even looking up at the computer screen.
• 12:16
  SPEAKER_01: Well, my application didn't allow them to do that, so that made their life worse, not better.
• 12:23
  SPEAKER_01: An example of this you may have seen if you're a C sharp developer is Visual Studio.
• 12:28
  SPEAKER_01: Visual Studio does this bad and good.
• 12:31
  SPEAKER_01: So let's talk about bad first.
• 12:33
  SPEAKER_01: If you right-click on a project in Visual Studio, that menu has gotten bigger and bigger and bigger over time.
• 12:43
  SPEAKER_01: And you know what?
• 12:45
  SPEAKER_01: There's more cool stuff in there, there's more great stuff in there, there's stuff in there that you know you need in theory, but that menu is just making it harder and harder to do the job.
• 12:59
  SPEAKER_01: Because if you just want to add something new to a project, ads not the top, you gotta search through and find it.
• 13:06
  SPEAKER_01: Or maybe you have to go and find that that project in File Explorer.
• 13:11
  SPEAKER_01: Well, that's down the middle somewhere, and you you kind of lose where things are because more things keep getting added, and now you have to spend more time reading through more items to find what you're looking for.
• 13:23
  SPEAKER_01: That's not a good experience.
• 13:24
  SPEAKER_01: You're making the user's life harder, not improving their life.
• 13:30
  SPEAKER_01: So, an example of how Visual Studio does it right.
• 13:33
  SPEAKER_01: If you have used IntelliCode in Visual Studio 2022, that's how you make the user's life easier, how you improve their life.
• 13:43
  SPEAKER_01: Because when you start typing code, it says, Hey, I think you're doing this.
• 13:49
  SPEAKER_01: If that's what you're doing, just hit tab.
• 13:51
  SPEAKER_01: That's awesome.
• 13:53
  SPEAKER_01: That's incredible because you know what?
• 13:55
  SPEAKER_01: I can say, Nope, that's not I'm doing, and keep typing.
• 13:57
  SPEAKER_01: Or you go look up and go, oh yeah, that's exactly what I want.
• 14:00
  SPEAKER_01: Hit tab.
• 14:01
  SPEAKER_01: And then if you do that, it goes, wait, you might want to do this next thing, right?
• 14:05
  SPEAKER_01: Just hit tab again and you do it again.
• 14:07
  SPEAKER_01: And it starts filling up more and more information and it makes your life easier and easier.
• 14:13
  SPEAKER_01: Um, the re quick actions refactoring as well, where you say, Hey, I want to move this class into its own file.
• 14:21
  SPEAKER_01: Boom, done.
• 14:21
  SPEAKER_01: Does it for you?
• 14:22
  SPEAKER_01: Hey, I want to rename this file to match the class, boom, done.
• 14:25
  SPEAKER_01: Hey, want to take the code behind or the code behind for Blazor and put it into its own file, boom, done.
• 14:32
  SPEAKER_01: That kind of stuff makes the user's life easier.
• 14:35
  SPEAKER_01: That's the kind of things that you need to do with your application in order to have a good application.
• 14:41
  SPEAKER_01: Make your user's life easier in some way.
• 14:44
  SPEAKER_01: That again means you need to be talking to the user.
• 14:49
  SPEAKER_01: So the three things to make good software.
• 14:54
  SPEAKER_01: Number one, have a clarity of purpose.
• 14:57
  SPEAKER_01: Know why you're building what you're building.
• 15:01
  SPEAKER_01: Number two, solve the right problem.
• 15:06
  SPEAKER_01: Understand what the problem is and solve that problem.
• 15:09
  SPEAKER_01: And number three, improve the user's life.
• 15:13
  SPEAKER_01: Make sure that your software is an improvement over what they had, not just prettier.
• 15:19
  SPEAKER_01: All right.
• 15:20
  SPEAKER_01: So thanks for listening to this week's episode of Dev Questions.
• 15:23
  SPEAKER_01: Check out the previous episodes for other questions that I've answered.
• 15:26
  SPEAKER_01: And if you don't know already, this is both a podcast and on video on YouTube.
• 15:31
  SPEAKER_01: So check out both options and use whatever is best for you.
• 15:34
  SPEAKER_01: Thanks for listening.
• 15:35
  SPEAKER_01: And as always, I am Tim Corey.
• 15:38
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 15:41
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 15:44
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share DevQuestions.
• 15:52
  SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
• 15:57
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 16:04
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in the course.