Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about how to manage a project that seems too big for you or your team to manage. Now this question is one that I've been discussing with Sean Washington from does not compute on our Slack channel which by the way you can join our Slack by going to spec.fm slash Slack P and I were discussing it and it just seemed like a great topic to talk about here on Developer Teabecause I think a lot of you are probably in a position where you're having to deal with these kinds of problems pretty regularly. A lot of you are probably freelance, freelance developers or you're on small teams. So I'm excited to talk about this. First I want to tell you a little bit about today's sponsor digital ocean and we will talk more about them later in the show but if you're looking for a hosting solution that you can get up and running with in actually less than a minute digital ocean is a great answer to that problem. We'll talk a little bit more later on in the show notes but I want to go ahead and dive in and talk about this topic of managing a big project managing a project that has a lot of specifications for example let's say you're building an application and you have a ton of what are called user stories a ton of minute features that you're trying to build. How do you keep all of these things straight? How do you know what's done? What's in progress? What is yet to be done? And how do you how do you verify that these things are done? How do you keep all of this stuff straight? Now there's a ton of information out there on managing projects. There's a lot of literature available on the agile methodology. There's a ton of literature available on Kanban and personal management managing your day-to-day tasks, managing your long-term tasks. There's getting things done GTD from David Allen. I mean there's just a ton of information out there and that's not the kind of things I necessarily want to focus on today because I don't want to rehash what everyone else has said before and the truth is that a lot of these things have some common themes but really it comes down to the individual what works best for you. I'm going to tell you just kind of a blanket statement for all of those methods. A lot of them work really well for one person or work really well for a lot of people but the only way that you're going to know whether or not something works for you is for you to try it and actually measure your results. Measure whether or not you're actually succeeding with that method and sometimes measuring is even hard. You have to actually eliminate a lot of the other factors that could be playing into the things that you're doing. For example, you have two different projects and you try to use two different methodologies on those two projects but you're not taking into account most likely that those projects are fundamentally different from each other. Running an experiment between two different methodologies, that may be a little bit difficult to do. This takes a lot of time and a lot of experimentation, a lot of effort to actually find the things that work best for you in the Serena. That's why there's so much literature out there because there are a lot of very valuable studies that have been done on this kind of behavioral psychology and how most people deal with massive problem sets like this. I highly recommend that you spend some time reading through some of this stuff but again, that's not what I'm going to cover today. I'm going to talk about three things that I think you should keep in mind when you're trying to do work on a large project of your own. Some of these are very specific to development too so I don't think that some of those other books are necessarily going to cover these things and that's why I wanted to talk about it on today's episode. Let's dive in with that first thing that I think you should keep in mind when you're working on a relatively large project. Number one, you can't and don't have to remember every detail of the project all the time. Let me say that again. You can't and you do not have to remember every detail of a project all of the time. That's because your brain simply can't, even if you tried, you would fail at this because it's nearly impossible to keep that much information in your working memory. In fact, it's much more efficient for you to focus on one small thing at a time. I recommend finding a tool that can help you keep track of the details. When I say tool, I don't necessarily mean an app. I mean a process that helps you keep track of the details, not every tool works for every person. For example, a lot of people love using GitHub issues. I actually don't use them very often. I know they're super powerful. I know there's a lot of compelling reasons to use them, but I choose to use a different methodology that I'll talk about in a second. A lot of people like keeping track with something like Wonder List or one of a hundred other to-do applications. Some people have found a way to make physical paper or a whiteboard work for them. My weird system is that I have a hybrid approach that uses Trello, which I'll put in the show notes. If you haven't heard of Trello, I love Trello. A lot of people use it for managing projects and it's much more approachable for people who are not developers, I would say, than GitHub is. But I use Trello and then I take a few things from my Trello board for a given project and I write them down on my notepad for the day and that's what I focus on for that day. Usually I don't open Trello unless I need a resource that has been dropped into that Trello board. But typically I stay out of Trello and I have that stuff on my notepad for the day. This isn't going to work for everyone, like I said, different processes, different tools work for different people. And I honestly don't know why exactly writing it down works so well for me. I think it has something to do with the fact that I've separated it from the screen and it's in a different context. Mentally, it's in a different context and I've spent more time actually writing it than I would have spent typing it out. But for whatever reason this has seemed to work relatively well for me. I don't necessarily even recommend that you try it out. But I do recommend that you try out many different things until you find some things that seem to work well for you. But don't try to remember everything. Get that information out. Get it into a place that is visible. Now I do think it makes sense to use something digital so that that data is available to you in some kind of cloud format. So you can go to your browser, for example, and find the things that you need to be able to find. I also use simple note, but that's not really for my to-do list. It's just to keep track of a massive number of details. I write all of my show notes and simple note before I do these episodes. That's a cloud-enabled little note pad service. Find something to put this stuff out of your brain and into some visible format, whether it's physical or digital. Just find something to get it out of your brain so that you're not trying to handle all of that information, trying to keep it straight in your mind. Now, as far as the actual methodology that I use on my Trello board, I tend to follow something similar to the Comban approach where I have kind of a backlog of tasks. And then I have things that are currently being done. And then I have kind of the validation phase where things are marked as complete. And typically it follows through that kind of pipeline approach. And that seems to work well for me. And it is a well-tested approach. I will include a link in the show notes that talks a little bit about Comban. I think it's a really powerful approach. And a lot of other people also really appreciate it. Subscribe to it as well. All right. So that's number one. You can't and you don't have to remember every detail of a project. All right. Number two, never invest unnecessary time into building customized tools if you can buy or implement them for the same price that it would cost you to build them unless they add a significant value to the product that you are building. Okay. Let me say that again. Basically, don't build something that you could instead buy or use an open source version of unless it adds significant value to whatever it is that you are building. For example, it's very likely that you shouldn't be creating your own image manipulation service instead of using a solution like Imagex. You probably shouldn't be writing your own CMS from the ground up. You shouldn't be writing your own web server from the ground up most likely. There are a ton of things that very likely you shouldn't be spending your time on. And instead, you can spend that time adding value directly to the product that you're creating, adding value to the work that you're doing for your client rather than replicating the work that somebody else has done. The other part of this is that if you try to build something totally custom, you are bringing along with that decision a lot of liability. You're taking a massive risk because any software that you build is very likely going to have problems just like any software somebody else builds. But the difference is if you're paying for software from another party, for example, or even if it's open source, there's probably somebody who is dedicated to fixing that software. And you're probably not totally dedicated to fixing that software. Instead, you're trying to build a product. And this is such a common problem. We see people doing this all the time trying to build their own custom slider or trying to build their own custom CMS. And unfortunately, they run into big issues, big bugs down the road that they end up having to fix. And the client isn't paying you to fix your own custom software. They're paying you to build a product for them. And unless that custom software is absolutely necessary, unless the functionality that you're building in a custom way is absolutely necessary for that product to succeed, then you very likely should opt for either open source or commercial software that stands in the gap where otherwise you would be spending a lot of time and a lot of resources fairly inefficiently. So that's a great time to take a moment and talk about today's sponsor, digitalocean.com. If you are looking for a hosting provider, digital ocean is that hosting provider. They are a perfect solution for those of you who want to have control of your own server, who want a cloud server, super fast SSD cloud server at that. And want to have a ton of space and a lot of bandwidth, but you also want to get up and running super fast. You can launch a cloud server on digital ocean in less than a minute. I actually did this myself. I went through the process of launching it and it works fantastically. And by the way, digital ocean has been kind enough to provide Developer Tealisteners with a $10 credit using the code Developer Tea. That is worth two months on their base plan. That's because digital ocean has a fantastic price point. So go and check it out digitalocean.com, make sure you use the code Developer Teaat checkout and you'll get a $10 credit. That's worth two months on digital ocean's base plan. Thank you so much again to digital ocean. So we've been talking about how to handle relatively large projects that feel a little bit too big for one person or for a small team. We've gone over two points that I think you need to remember. Number one, you don't have to remember everything. You don't have to keep it all in your mind, use a tool or a few tools or a process to help you get that stuff out of your brain and into a readable format. Number two, you should never invest unnecessary time into custom solutions that don't provide a significant value to the product if those custom solutions can be found in open source or commercial software. And number three, you need to ensure yourself against code collision. Now this is the most practical tip of these three. You need to ensure yourself against code collision. One of the most common causes of failure is when the code from one part of the code base ends up affecting code from another part of the code base that was written at a different point in time. So how can you prevent this kind of problem? Well there's two ways that I'm going to talk about today but there's literature that abounds about the subject. So we're going to keep it short today. Let's look for more information on this in the future and I'll probably include a few links in the show notes that talk about code collision. But number one, you need to be writing integration regression tests. Now that's the easy way of saying you need to be writing integration tests that test the features that you're writing today so that when you write new code tomorrow, you're making sure that you didn't break the features that you wrote today. You need to write integration tests that test the stuff that you've already written so that when you write new stuff in the future, the stuff that you wrote in the past doesn't break. And if it does break, which it will, you know exactly why and where it broke. Now you're doing it wrong. If you are going back and doing this manually, it is absolutely a waste of time to try to go through and click through every part of your application, especially if you're at the scale that we're talking about in today's episode, so you need to be writing these tests so that they can run programmatically. I've worked on projects that have upwards of a thousand integration tests. So it's totally worthwhile to do that because running a thousand integration tests by hand every time you add a new feature is completely infeasible and in fact, probably impossible to finish a project like that. One to mention the fact that these integration tests, they are much more accurate than a human would be. So make sure you're writing integration tests and treat them as tests that keep you safe both now and in the future. Number two, make everything smaller. Make everything smaller. And then you connect the dots. This is a very common theme when you start looking at the literature that I mentioned previously about code collision and making a well-designed software. Small classes are a huge help in controlling these kinds of collision issues. Now you will see these problems rising as you create huge classes or massive script files or big monolithic style sheets, for example, or really anything that combines multiple responsibilities into the same scope or into the same file. You're setting yourself up for major failures and major difficulties in trying to manage your code. You're forcing your brain to try to hold more in its immediate memory than it was designed to hold. So separate your code into logical, well-scoped containers that usually means creating many small classes or if you're working in a functional environment, creating a lot more functions than you may have originally thought you would need. So take advantage of the scope and be militant about avoiding collisions and about avoiding global namespace issues. This will keep you from running into those collision problems more often. So that wraps up the three main points that I have. But I have one more thought for you and it's kind of like a bonus thought because as I was recording the episode, I remembered one of the most important things that I do to keep myself from messing up. And that is I write checklists for processes that I repeat more than once. So for example, we have a launch checklist at Whiteboard and we have little tiny details in that checklist that we verify or complete before we can launch even the simplest of websites. And this keeps us safe because a lot of those small, insignificant things can come back to bite you a day later. But say for example, that you forget to unblock search engines from finding your site. Well, if you leave that undone, it's very unlikely that it's going to produce a bug necessarily. But you need to unblock the search engines. If you're a web developer, you know the importance of this. You need to unblock those search engines for that site to be found by Google. So you could go, you know, a month or two down the road and never know what happened. And there are sites out there right now that the developer opted to not have Google crawl the site for the development period, but they forgot to turn it off because they didn't have a checklist to tell them to turn it off. And so checklists help us remember things that are otherwise relatively easy to forget. So write out a checklist for the things that have a lot of small steps that you do over and over this will help you make sure that you don't forget a step that is otherwise easily forgettable. Thank you so much for listening to today's episode of Developer Tea. I hope it has given you some ideas and some inspiration for how to handle a project that feels too big to handle. Thank you again to today's sponsor Digital Ocean. If you are looking for a cloud hosting provider, go no further than digital ocean.com. And forget the code Developer Teato get two months for free. That's a $10 credit at checkout. That's two months on the base plan at digital ocean.com. Super fast SSD servers that they provide over there. You can get up and running in less than a minute digital ocean.com. Thank you so much for listening to this show and all of the shows on spec.fm. If you are not aware, Developer Tea is a part of the spec network of podcasts. You can go and find other shows and other great content at spec.fm. And you can find all the show notes from this episode at spec.fm. If you listen to Developer Tea and you enjoy it, you get a lot of value out of the show. The best way that you can kind of give back to the show is to go to iTunes and leave a rating and review. This is the easiest way to help us out. And it happens to help other people out because it pushes the show up in the ratings which helps other people just like you find Developer Tea. Thank you so much for helping the show out. Thank you for listening and until next time, enjoy your tea.