Have you ever seen a feature go from what seemed to be really simple to incredibly complicated? Why does that happen? In today's episode, we're going to be talking about planning. This is going to be one in a series of episodes that we're going to do. There's probably going to be some interview episodes in between some of these, but a series of episodes that I want to do based on project planning. We are going to be talking about planning in terms of identifying every single feature up front. We're going to be talking about it more holistically in terms of what are some things that you should be thinking about when you're planning. What are some ways to avoid pitfalls like, for example, a feature going from what's supposed to be a very simple feature to a really complicated feature and really not changing much of the underlying functionality. That's what we're talking about in today's episode of Developer Tea. My name is Jonathan Cutrell. You are listening to Developer Tea. My goal on this show is to help you become a better developer. I do that by coaching you through some of this stuff. You may have never planned a project that took longer than a week. Maybe your early, early days as a web developer or as a native application developer. Perhaps you've never had the chance to deal with some of this complexity. That's what we're going to be doing here to help you become a better developer. I want to give you a perspective that maybe you haven't had the chance to gain the experience for that perspective or maybe you do have the perspective but you're forgetting some of the fundamentals or you need to be reminded of some of these things. Ultimately, even those of you who are very experienced, you and I, if we were to sit down and have a cup of tea together, we may not necessarily agree on all of this stuff. One of the best ways to learn is to compare our opinions, to come at the same subject and bring differing perspectives, differing opinions, different experiences from each other and comparing contrasts those things. Even if you are experienced, even if you've planned 100 projects or 1000 projects before, this is still going to benefit you because us sharing our opinions together, that is one of the best ways that we can perfect the things that we do. We're never going to arrive. Hopefully that's not going to hurt anybody's feelings or disappoint any of you. You're never going to finish getting better. That's why the show really has no end in mind. You're never actually going to finish getting better. You're never going to end your learning processes. You're never going to end your journey. This is really not about arriving as much as it is about constantly refining, constantly getting better. It's like an equation that approaches infinity but never quite gets there. That's what we're talking about. We're talking about planning. More specifically, I want to focus on this one interesting aspect of planning. I've run across this quite a few times. There's some questions that you can ask that a lot of developers forget to ask to avoid this pitfall. I want to set up this scenario before we talk about our sponsor for the day. The scenario is you sit down with a client or perhaps you and your co-workers or investors. You sit down and you figure out a series of features to build in your application. These features can be anything really. We want to allow users to sign up. We want to allow a given user to change their password. These are really common features. You write all this stuff out. You figure out how complex each of these things are. Maybe you're following the agile methodology. You think you have all the details down and then you go into actually developing the project. One of these features just blows up out of nowhere. What is the cause for this? That's what we're going to talk about. I'm going to give you a few antidotes to help you avoid that feature bloat. It's not even feature bloat, really. To problem with gathering the right details in advance, we're going to talk about that right after we talk about today's awesome sponsor, Linode. Today's episode is sponsored by Linode. Now I don't have the sponsor read in front of me. The reason for that is because Linode has been sponsoring Developer Tea for quite a while now. Not only do I know these pricing numbers that are really quite good, by the way, but I also understand really the value that Linode provides to developers. The reality is Linode has so many features beyond just providing you access to a Linux server. Linode provides you additional value that most other providers don't have. Really the dollar program is the best in the industry. Their servers are built on solid state disks. They're super fast. They have a 40 gigabit internal network. You can network multiple Linode servers together, but you also get incredible service, 24 seven service, and their plan started just $5 a month. You can get started very quickly with Linode. You can get a server running in just a few minutes, a couple of clicks. Of course, you can orchestrate massive, very powerful servers on Linode with their API as well. You could set up your system to balance across a array of servers if you wanted to, and Linode supports all of that. They have services on top of what they provide. They also have services that you can hire to help you orchestrate this stuff. Go and check it out. This is for the very entry level all the way up to the very complex needs. All of those can be mapped by Linode. Go and check it out. If I'm slash Linode, they're going to give you $20 worth of credit today for using the code Developer Tea2017. Thank you to Linode for sponsoring Developer Tea. So we're talking about why a given feature might blow up unexpectedly. We go through these processes of defining user stories and we try to understand a feature before we get into building it. Sometimes once we build that feature and it goes live or maybe in the process of designing it and then translating some visual design into the actual development of that feature, something goes awry, something explodes the scope of that particular feature. Now, I'm going to help you avoid this by giving you a few antidotes for this kind of thing. The first thing that you want to do is approach this problem, approach avoiding this problem by understanding both the scale and the specifics of your user. So what does that mean? Understanding the scale and the specifics. The scale is quite simply asking how many of this thing need to be supported. For example, how many users need to be supported? If your system allows logins, how many users are going to log into this thing? And the answer may be a range. Perhaps you are actually creating a startup that's intended to go and kind of be marketed to everyone and you want there to be support for a large number of users. It may also be intended to only support a limited number of users, like for example, an internal application at a company. And you need to understand how that number changes over time. So perhaps the application that's intended to be marketed to everyone in the world, maybe it's actually only going to be marketed to one city to begin with and then slowly grow over time. Or maybe it's even a smaller group, a beta testing group. And you don't really have to necessarily build all of those features to scale right away. Here's the reality. If you don't gather this information, then you are building based on an assumption. You're building based on some kind of assumption of how many users this application needs to support. And we aren't just talking about users. We're also talking about, for example, if you're something very simple, if you're creating a blog, how many posts should this blog support? A lot of times we forget very simple things like pagination. And those end up biting us down the road because we didn't set ourselves up for success by understanding what scale of things do we need to support and on what timeline do we need to support those things. A simple proof of this is a single admin application, like for example, a publishing application that really only needs one or maybe two logins. Well, there's not really a good reason to create an entire user management system for that application, right? Because it's so much more overhead to invest in that and the feature really doesn't justify that much investment. So to avoid that feature explosion, understanding the scale, you can actually start to understand how much investment is needed for this feature to be accomplished. And on the other side of this, we mentioned understanding the specifics of your user. What kind of people are using this particular application? A very simple example once again is the publishing platform. You can ask a question like, does the user understand how to write HTML? Does the user have an understanding of cascading style sheets? And they reference an existing cascading style sheet and write HTML into a single block and can we trust them to be able to publish and manage that HTML? Most of the time, the answer is no. And a lot of times we assume that the answer is no. But it's very possible that you can avoid a lot of complexity if the answer is yes. So it's worth asking these kinds of questions. Another question might be, what level of translation support do I need to build into the administrative interfaces of my application? These are the kinds of questions that need to be answered from understanding who is using the application. Who is this feature being built for? So who and how many? These are two questions that actually manage your scale. They manage your complexity and eliminate the assumptions that end you up in a position where you either underscoped the feature or you way overscoped the feature. So this is very important to understand not only for, once again, not only for user accounts, but also for every kind of thing that your application is managing. So let's say you're building a commerce application. Your commerce application doesn't really need to support multiple currencies. So if you try to build multiple currencies in from the beginning, you may be overbuilding. On the flip side, it very well may need to support every currency. What you shouldn't do, what you can't do, is let that question go unanswered. Don't answer that question during implementation and don't answer it when it becomes a problem. Try to answer these kinds of questions preemptively. Try to understand the problem space and the problem scale. Thank you so much for listening to today's episode of Developer Tea. My name is Jonathan Cutrell. Once again, thank you so much to Linode for sponsoring today's episode. With Linode, you get excellent customer service, the best dollar per gigabyte of RAM deal on the market. And a free $20 bill, effectively $20 worth of their services, by going to spec out of them slash Linode in using the code Developer Tea2017 at checkout. That's Developer Tea 2017. Thank you again to Linode for sponsoring today's episode. Thank you so much for listening. If you're enjoying these episodes, and if you want to hear more about planning, we're going to be doing some more episodes around this theme of planning and understanding how to prepare for a project and how to prepare during a project. If you want to hear more about this stuff, make sure you subscribe in whatever podcasting app you use. We're going to be talking about this and many other valuable topics on this show in the future. Thank you so much for listening. And until next time, enjoy your tea.