Latest / DevQuestions with Tim Corey / 095 How Do I Plan Out A Project? Waterfall? Agile?

Transcript

095 How Do I Plan Out A Project? Waterfall? Agile? · 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_02: How do I plan out a project?
• 0:27
  SPEAKER_02: Should I do everything using waterfall, or is Agile the best approach to building a project?
• 0:34
  SPEAKER_02: And this is a common question that comes up and one that I think needs to be delved in more deeply.
• 0:40
  SPEAKER_02: So let's address this in today's episode of DevQuestions.
• 0:44
  SPEAKER_02: Now, first, let's talk about the big two really, which would be waterfall and agile.
• 0:50
  SPEAKER_02: There are two different approaches to planning out and building a project.
• 0:55
  SPEAKER_02: The first is waterfall, which is kind of the old school way of doing things, which is that you fully plan out a project first, and then you execute it as in build the entire project, and then you test it.
• 1:09
  SPEAKER_02: And that's kind of the very high-level, very um simplified version of waterfall development.
• 1:17
  SPEAKER_02: Agile takes a different approach, and that approach is hey, let's put something in the hands of the customers much, much earlier.
• 1:24
  SPEAKER_02: That way we can iterate and change and grow as needed.
• 1:28
  SPEAKER_02: So is this idea of cycles, small bits of programming where you do a little bit of programming, a little bit of planning first, a little bit of programming, and then testing.
• 1:38
  SPEAKER_02: And you'd get one feature out or one little bit out, and then you move on and do it again and again.
• 1:43
  SPEAKER_02: And the idea behind that is that the earlier a person sees the uh the product working, the more they can say, hey, I want to tweak this or tweak that, and it doesn't change the entire application.
• 1:57
  SPEAKER_02: So again, very high level.
• 1:59
  SPEAKER_02: I've left a lot of stuff out, but that's the basics of waterfall and agile.
• 2:07
  SPEAKER_02: So let's talk about which one is best.
• 2:10
  SPEAKER_02: I think that right there is the clue that neither is the answer.
• 2:17
  SPEAKER_02: And that's because whenever you look at anything in a software development realm, if you come into it saying there is one right answer for everything, then you're probably wrong.
• 2:32
  SPEAKER_02: Because whenever we go to an extreme, we leave out too many things.
• 2:37
  SPEAKER_02: We we say, hey, those edge cases don't matter.
• 2:41
  SPEAKER_02: And we'll do it anyways, we'll force this way everywhere.
• 2:46
  SPEAKER_02: So I would encourage you, don't get stuck in the idea that we have to do it the same way for every single project.
• 2:56
  SPEAKER_02: Now, let's talk about the benefits of waterfall.
• 3:00
  SPEAKER_02: The benefits of waterfall are that you get a consistent product.
• 3:05
  SPEAKER_02: When you plan it out up front, you plan the entire thing as one big chunk.
• 3:10
  SPEAKER_02: You have a complete picture of what you want to build.
• 3:15
  SPEAKER_02: That way, when you execute, you have in mind that complete picture.
• 3:20
  SPEAKER_02: When you get to the end, you've turned in something that hopefully matches your plan, which the customer should have signed off on at the beginning.
• 3:30
  SPEAKER_02: In that case, you have a solution that meets the requirements, and that can be a great thing.
• 3:38
  SPEAKER_02: The downsides, though, are that it's very rigid.
• 3:43
  SPEAKER_02: Once you plan something out, you can't really adjust over time because you're meeting that original plan.
• 3:51
  SPEAKER_02: And that plan may have been built a year ago or two years ago, depending on the size of the project.
• 3:58
  SPEAKER_02: So that can be very rigid, which also means that the user doesn't actually use the application until the very end.
• 4:07
  SPEAKER_02: So if the user says, Hey, I don't really like this part of it, it's kind of too late.
• 4:13
  SPEAKER_02: You're gonna have to do a lot of work and really start over from the beginning of, okay, we're gonna plan this new thing out, we're gonna plan the adjustments, make the adjustments, and then show them to you.
• 4:24
  SPEAKER_02: That's a lot of work and a lot of effort and a lot of wasted time.
• 4:29
  SPEAKER_02: It's a somewhat dangerous process to walk through because you're you can be likely to see your end results rejected by the customer as not what they really wanted.
• 4:42
  SPEAKER_02: Because customers typically don't know exactly what they want to see.
• 4:47
  SPEAKER_02: They have an idea, but they often miss pieces or forget about things or don't really think through how it'll work in the real world.
• 4:55
  SPEAKER_02: So that can be a danger of waterfall.
• 4:58
  SPEAKER_02: Agile, on the other hand, the benefits are that you get to see something right away.
• 5:03
  SPEAKER_02: The customer gets to play around with maybe a very, very small bit, but they get to see that one small bit.
• 5:10
  SPEAKER_02: And they can say, hey, I like that, or uh, I'm not a big fan of that.
• 5:15
  SPEAKER_02: And so they can, you can iterate then and say, Oh, you don't like that?
• 5:20
  SPEAKER_02: What if we tweak this and change it?
• 5:22
  SPEAKER_02: And they say, Yes, I want that.
• 5:24
  SPEAKER_02: And now your product has made some changes, you change the direction slightly of the project, but you haven't lost much, if any, work.
• 5:33
  SPEAKER_02: Instead, your next cycle can take that into account and adjust the end result.
• 5:39
  SPEAKER_02: So there's some very big positives when it comes to agile.
• 5:43
  SPEAKER_02: The downsides are that you often don't know exactly where you're going.
• 5:49
  SPEAKER_02: You don't know exactly when you're gonna end up, or you know, when or if you're gonna end the project, where your project will be at the end, what it will look like or how it will work, because you're constantly iterating and changing.
• 6:03
  SPEAKER_02: This can lead to budget overruns, it can lead to time overruns, it can lead to a frustration as well, because you're never really done.
• 6:14
  SPEAKER_02: So there are some downsides with agile as well.
• 6:19
  SPEAKER_02: If you come into one viewpoint and say, well, there's only positives here, you're not really being objective.
• 6:27
  SPEAKER_02: Okay.
• 6:28
  SPEAKER_02: So make sure you look at the negatives as well and say, I accept those negatives because of the positives.
• 6:36
  SPEAKER_02: Now, how do I do things?
• 6:38
  SPEAKER_02: Well, it depends on the project.
• 6:41
  SPEAKER_02: And this is the very important thing to learn as a developer.
• 6:44
  SPEAKER_02: When you're doing development, you should not pre-make your decisions and then try and force your project into those decisions.
• 6:52
  SPEAKER_02: Whether it is what type of project you're gonna use, uh, what process you'll use to build the project, how your team will work, all those kind of things shouldn't be predetermined for the most part.
• 7:04
  SPEAKER_02: Because otherwise what happens is you don't get the best result.
• 7:09
  SPEAKER_02: So try to look at your project first and then see what's gonna work best for this project.
• 7:15
  SPEAKER_02: For instance, a small project really needs waterfall.
• 7:19
  SPEAKER_02: It's the simplest way of going about it.
• 7:22
  SPEAKER_02: You plan everything out, you build it, you test it.
• 7:26
  SPEAKER_02: Because there's not really a need to do this iterative process when the project's small.
• 7:30
  SPEAKER_02: If a project is massive, you probably need to have more of an agile approach where you build out pieces of it, make sure that you're not just wasting a year, two years, three years worth of development time because you had an assumption that was wrong.
• 7:49
  SPEAKER_02: So there is a balance based upon your project.
• 7:52
  SPEAKER_02: For me personally, generally, when I come to a project, if it's not too small or too big or have other extenuating circumstances, what I do is a hybrid approach.
• 8:04
  SPEAKER_02: I tend to plan out the high level of my project from the beginning.
• 8:10
  SPEAKER_02: I try to get a rough sketch of the project and a big idea of what are the hurdles we'll have to go through in each different section.
• 8:20
  SPEAKER_02: I do try to draw out the various user interfaces to make sure that I understand what will be there.
• 8:27
  SPEAKER_02: I try and sketch out what data am I going to need.
• 8:30
  SPEAKER_02: And then that can determine what kind of database or data storage I'll use.
• 8:35
  SPEAKER_02: But the other part here is because I kind of draw this out and sketch it out, I can take those drawings to the customer and say, let's walk through this as if you're using my interface.
• 8:47
  SPEAKER_02: It's the completed interface, or at least a rough draft of it.
• 8:51
  SPEAKER_02: So they can put a piece of paper on a desk, they can look at the user interface, they can visually think through, okay, I would type in this field, I would check this box, I would hit this button.
• 9:03
  SPEAKER_02: And if they hit that button, I'd say, okay, that button, I flip four pages, goes to this screen.
• 9:09
  SPEAKER_02: This is what's going to look like.
• 9:10
  SPEAKER_02: And they can kind of practice with a test user interface.
• 9:15
  SPEAKER_02: They can try things out.
• 9:16
  SPEAKER_02: This also works on a whiteboard where you draw different things out and kind of walk them through the process.
• 9:22
  SPEAKER_02: By doing so and by having that uh pretend user interface, it does a few things.
• 9:29
  SPEAKER_02: First of all, it can reveal some of those assumptions where they say, okay, and this this will happen.
• 9:36
  SPEAKER_02: And I say, Whoa, whoa, how does that happen?
• 9:39
  SPEAKER_02: Because we don't have that in the design.
• 9:42
  SPEAKER_02: And that's when you say, Oh, okay, I expect when I do this that these things will happen.
• 9:47
  SPEAKER_02: And that adds to your design.
• 9:50
  SPEAKER_02: But also, it puts something in front of the user that they can walk through and say, okay, this is missing, or I like this over here a bit better, without going too far into details.
• 10:01
  SPEAKER_02: When it's sketched out, when it's on a whiteboard, when it's obviously a rough draft, you don't focus on things like font sizes, coloring, uh, the size of buttons, the the exact layout on a screen.
• 10:17
  SPEAKER_02: You're talking about the high-level things.
• 10:20
  SPEAKER_02: It allows people, it frees people up to just focus on those things because they know this is obviously not the final product.
• 10:29
  SPEAKER_02: If you decide to put this into Visual Studio, make a mock-up of it, make it really work in a test scenario, what happens more often than not is that test application that you made with ugly code that you roughed in just barely works, somehow that ends up becoming production code.
• 10:50
  SPEAKER_02: That's not a good thing, but it happens all the time.
• 10:53
  SPEAKER_02: So I encourage you, don't create those practice or mock-ups using real tech.
• 11:01
  SPEAKER_02: Because the closer it looks to real, the more likely the user is to get confused with real and they start judging things like the font sizes and the button sizes and layouts, and they don't focus in on how the application works, and they expect your application to be done very, very quickly because they already see it and it seems to already work.
• 11:22
  SPEAKER_02: So I try and have a sketched overview of the entire application.
• 11:27
  SPEAKER_02: I try and sketch out the data I need and then the the big pieces.
• 11:33
  SPEAKER_02: Do I need a NoSQL database like MongoDB or Cosmos DB?
• 11:37
  SPEAKER_02: Do I need a relational database like SQL or MySQL?
• 11:40
  SPEAKER_02: Where am I hosting this?
• 11:42
  SPEAKER_02: What types of technologies will I use?
• 11:45
  SPEAKER_02: What are the big pieces?
• 11:46
  SPEAKER_02: Do I have emailing?
• 11:47
  SPEAKER_02: Am I sending text messages out through this application?
• 11:50
  SPEAKER_02: Is it working with a NuGet library or something else?
• 11:56
  SPEAKER_02: And so I have these big ideas on the high level of what my application will need.
• 12:02
  SPEAKER_02: This is somewhat waterfall-esque.
• 12:06
  SPEAKER_02: However, I then go into more of an agile process of building this.
• 12:11
  SPEAKER_02: I have the big overall plan, but then it can still adjust because it's a rough draft.
• 12:18
  SPEAKER_02: It's the general idea of how the application works.
• 12:22
  SPEAKER_02: And then I start building a piece at a time.
• 12:24
  SPEAKER_02: I rough in and get one little piece working.
• 12:27
  SPEAKER_02: I show it to the customer and say, hey, this is what we're thinking about for this section.
• 12:32
  SPEAKER_02: That way I get the benefits of that agile process of showing the customer and being able to iterate quickly.
• 12:39
  SPEAKER_02: So I get something working as soon as possible, even if it's a little piece of it.
• 12:45
  SPEAKER_02: And I keep building out from there.
• 12:47
  SPEAKER_02: That allows me to test, it allows me to understand the application better.
• 12:51
  SPEAKER_02: It allows me to show the end user and get their sign-off and continued approval of yes, this is the right direction.
• 12:58
  SPEAKER_02: It allows me to adjust quickly as things go on.
• 13:02
  SPEAKER_02: And yet, I have the overall plan.
• 13:05
  SPEAKER_02: I know the overall scope of the application, and I know roughly how long the application will take to build.
• 13:11
  SPEAKER_02: So I have the benefits of waterfall, I have the benefits of agile, and while there are some drawbacks, they aren't nearly as bad as pure agile or pure waterfall.
• 13:23
  SPEAKER_02: So that's my personal opinion, but you can do things differently.
• 13:27
  SPEAKER_02: I would encourage you not to get locked up in a war over which one is best.
• 13:34
  SPEAKER_02: Instead, find out what works for your project, find out what works for your team, find out what works best for your organization, and do that.
• 13:43
  SPEAKER_02: Okay.
• 13:44
  SPEAKER_02: So don't get focused on terminology or what's old or new.
• 13:49
  SPEAKER_02: Focus in on what works best for you.
• 13:52
  SPEAKER_02: That's my thoughts on Agile versus Waterfall and how to plan out a project.
• 13:57
  SPEAKER_02: Okay.
• 13:58
  SPEAKER_02: Thanks for watching.
• 13:59
  SPEAKER_02: If you have a question about anything developer related, then go to suggestions.imtimcorey.com, leave a comment there, mark it as a dev question comment if it's for this type of format where you're asking about the process of building applications or being a developer.
• 14:17
  SPEAKER_02: And then hopefully you'll see your answer brought up and your question brought up and answered in a future episode of DevQuestions.
• 14:26
  SPEAKER_02: Thanks for listening.
• 14:27
  SPEAKER_02: And as always, I am Tim Corey.
• 14:29
  SPEAKER_01: Thank you for joining us for this episode of Dev Questions.
• 14:32
  SPEAKER_01: Tim is committed to making it easier for you to become a developer.
• 14:36
  SPEAKER_01: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 14:43
  SPEAKER_01: You can also send your questions to questions at IamTimcorey.com.
• 14:48
  SPEAKER_01: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 14:55
  SPEAKER_01: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.