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 aren't 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. So that's what we're talking about in today's episode of Developer Tea. My name is Jonathan Cottrell. 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. It may be your early, early days as a web developer or as a developer. It may be a native application developer. Perhaps you've never had the chance to deal with some of this complexity. And that's what we're going to be doing here. To help you become a better developer, I want to give you 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. And ultimately, you're going to be able to do a lot of things. 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. And 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 compare and contrast those things. So even if you are experienced, even if you've planned. A hundred projects or a thousand 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. And 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. So that's what we're talking about. We're talking about planning. And more specifically, I want to focus on this one interesting aspect of planning. I've run across this quite a few times. And there's some questions that you can ask that a lot of developers forget to ask to avoid this pitfall. But 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. And 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. And you write all this stuff out. You figure out how much, how complex each of these things are. Maybe you're following the agile methodology and you think you have all the details down. And then you go into actually developing the project. And one of these features just kind of blows up out of nowhere. Right? What is, what is the cause for this? That's what we're going to talk about. And I'm going to give you a few antidotes to help you avoid that feature bloat. It's not even feature bloat really. It's a 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. And the reason for that is because Linode has been sponsoring Developer T for quite a while now. So 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. And 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. And really the dollar per RAM is the value that you can get. And the reason for that is because Linode is the best in the industry. Their servers are built on solid state disks. So they're super fast. They have a 40 gigabit internal network. So you can network multiple Linode servers together. But you also get incredible service. 24-7 service. And their plans start at just $5 a month. So 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. So you could set up your system to balance across an 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. So go and check it out. This is for the very entry level all the way up to the very cutting edge. All the way up to the very complex needs. All of those can be met by Linode. Go and check it out. spec.fm.linode They're going to give you $20 worth of credit today for using the code developerT2017. Thank you to Linode for sponsoring developerT. 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. And 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? 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 used is going to be a large number of users. And if it's an 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, based on a prediction of how many users this application needs to support. And we aren't just talking about users. We're also talking about, for example, 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, 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? Can 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? 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. This is very important to understand, 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. Maybe 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 Cottrell. 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.fm slash Linode and using the code developertea2017 at checkout. That's developertea2017. 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.