Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about creating feature runways but first I want to think spec.fm. We don't have an official sponsor for today's episode but spec is what makes Developer Teahappen day in and day out. We are constantly working on this show as well as other things on spec.fm. Like for example the spec Slack channel or Slack community, I guess channels are the individual chat rooms inside of Slack but if you would like to join the Slack channel it's totally free. You can come and talk to me, you can talk to Brandon Bryan from Design Details and everyone else that's a part of the spec community you can sign up for free at spec.fm slash Slack and of course I'm there pretty much all the time. You can always ask me questions and you may even hear them on the show. Check it out spec.fm slash Slack. We'd love to have you. There are a ton of awesome people who are leading in this industry that are in there as well. Who knows you may get a chance to talk to them so check it out spec.fm slash Slack. So I want to keep today's episode short. I know it is a Monday when this episode is being released. You have a lot of stuff to do and so do I. So I want to go ahead and jump right into the topic which is creating feature runways. Now what exactly is a feature runway? Well you're not going to be able to find it on Google because I made this term up today. This is something that I've been trying to figure out exactly how to express it in words. And I'm deciding to call it future runways because well my dad was a pilot but also because I think runway is a good way of explaining a future development, a path that lays out in front of you for you to go down or that you expect to go down. You could call them future trails or if you want to call it something else that's totally fine but the concept is very simple and it is if you have an idea of what might happen in the future in a given application. If you have an idea of certain features that you may need one day or if you have some idea of a particular area of the application that is going to grow in complexity or is most likely to grow in complexity but you aren't building it today you still need to create a runway for it. In other words you need to create the fundamental kind of base level code in order to iterate in an easier way. So an example of this. Let's say you're creating a blog kind of application where you want to have a post and you create the post to have a featured image. Well it's very likely that down the road you're going to want to be able to attach more than just one image to that blog post. So it would make sense for you to go ahead and create rather than a single image to a single post relationship you can create a post to many images relationship and only use one for now until you decide that you want to use many. Another example of this is if you're creating some kind of e-commerce platform and you only sell t-shirts now but maybe you're going to sell another thing later maybe you're going to sell shoes later for example. It makes sense for you to go ahead and make some of those structures flexible. Don't hard code the word t-shirt for example into the code go ahead and offset that so that scaling into shoes or let's say 30 other products is relatively easy to do. Now of course you have to be the one or you and your team you have to make the determination of what things need to be flexible. What direction do those runways go down? Of course you don't need to over engineer flexibility into your applications because that's just wasted time but sometimes flexibility is relatively simple to implement. In other words sometimes it's just as easy to go the flexible route and you save yourself a lot of time potentially. In other words it doesn't take a lot of energy to create a many to many relationship but if you were to have made the mistake of not creating it in the beginning and you need it later well that's going to take a significant amount of energy. This idea of future runways really it's like an insurance policy. If you see areas where your application is likely to grow then go ahead and build those areas a little bit more flexibly. Go ahead and start thinking down that road and build yourself into that direction and you will thank yourself later that you have that insurance policy that that little bit of extra effort saved you a lot of time in the long run. Thank you so much for listening to Developer Teaon this beautiful Monday hopefully it's as beautiful there as it will be here. Chattanooga's always a beautiful place to be. I expect to see you in the slack room the spec slack room. It is spec.fm-slack you can find that in the show notes as well as a link to leave Developer Teaa review on iTunes. That is a huge way of helping me out especially if you find value in this show. I would like to ask you for that favor of leaving a review in iTunes for Developer Teaas a huge help to the show. Thank you again for listening and until next time enjoy your tea.