What code do you need today? That's what we're talking about on today's episode of Developer Tea. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers connect to their career purpose and to help them do better works so they can have a positive influence on the people around them. In today's episode, we're talking about a particular code smell in this episode and next episode you're going to be about code smells. But this is a more conceptual code smell. It happens as a result very often of a business kind of objective that we translate into our code. And I want to talk about it because I think it's something we all do and sometimes we do it without even realizing it. Sometimes we incorporate this stuff because we really have a high level of confidence in our business decisions. This isn't a bad thing. If you work for example on behalf of a business owner, let's say you are a freelancer or you are an individual contributor developer and you are not the person that's making the business level decisions. Where is this product going to go? The product ownership decisions and the product management decisions. You're not making these decisions. And so you as the developer, you are receiving some information and of course in a healthy team you're collaborating about this information. You're trying to provide the reasonable technical information to help those people make good decisions based on their resources. And as you're implementing this code for the feature that is being asked for, you're realizing that this is the place that a future feature, say that five times fast, future feature is likely to show up. For example, let's say you are working on some kind of shopping cart and you maybe you're living in the United States, you're implementing sales tax for the state that the company is operating in. Especially if this is a physical location for this particular business. And so instead of implementing for just that state, you start to think, okay, I should probably implement sales tax for other states as well. And then you implement sales tax for other states. But in order to do that, you have to create the concept of multiple states. And while you're at it, maybe go ahead and create some kind of international way of dealing with things, whether that's sales tax or maybe you start thinking that you should start creating shipping costs, shipping estimates. And so you start building out the structure, even the kind of the foundation, even if you weren't necessarily building it all the way out, you're building this, these foundational things for features that are going to be added in the future. Or at least that's what you expect to expect those features to come into the future. Another example of this, let's say that you're building an application and you expect, or at least you suspect, that the application is going to be white labeled, that it's going to be multi-tenant. In other words, you're going from one to many, let's say, domains that it's going to live on, for example. And so out of the fear of being inflexible later, you try to build this system with flexibility on day one. Now, if you've been in this place, you probably know that it can be painful. And we're going to talk about why, in just a moment, right after we talk about today's sponsor, Reactor. Reactor is a digital product studio in New York City, designing and building products and services for forward thinking businesses and organizations. By the way, Reactor is spelled by the K. That's because the Finnish language doesn't use the letter C. That's R-E-A-K-T-O-R. And they take this Finnish heritage really quite seriously. Relationship is a high priority for the people at Reactor. But not at the expense of work. They've partnered with people like HBO and Supercell and Viacom. Even Finair, they designed and built the digital customer journey for Finair, including their onboard experience. This Finair is the Finnish airline, by the way. So they're developing their own satellite to explore emerging new space business opportunities. That's new space business opportunities like opportunities in space for business from hardware to rethinking putting code into space. This is literally launching in the orbit later in 2018. So we're telling you all about Reactor because Reactor is hiring. They're looking for great software engineers for a number of product roles with different emphasis on the wide context of product development. Instead of pre-defining the position, though, they're not going to give you a job description. Instead, they want you to reach out and explain what your skills are, explain what your experience is, your ambitions, and ultimately your dream role. Head over to Reactor.com. Remember that's R-E-A-K-T-O-R.com slash careers. Thanks again to Reactor for sponsoring today's episode of Developer Tea. So we're talking about why this future feature development or even preparing for these future features, why this can get us in trouble. I'll give you one more example. So maybe if you didn't connect with the other two examples, maybe you will with this one. This happens very often with user account information. We try to add a lot of fields that we may want to track in the future. We had first and last name and email, and that may be enough for our launch, but we want to carry that forward. We add the zip code and perhaps a whole slew of other fields. Now this doesn't necessarily create a lot of technical debt per se. But often what ends up happening is we start tripping over this code for a couple of reasons. One often this code goes unfinished because it isn't really needed. It's kind of in the way and it wasn't really prioritized. So very often this code only gets some of our attention. Sometimes placeholders are put into place and they aren't really doing anything. The test coverage is often poor. Certainly the interface isn't really reflecting those features. So we have these kind of second class citizens in our code. Sometimes those second class citizens also require us to make our code more complicated than it needs to be. In the example where we need to support multiple tenants, maybe we don't really need to support multiple tenants for a few years in the product that we're building. So we're having to go through all of the technical work to support tenants today that ultimately wouldn't be all that hard when we are scaled up and we really need it. The benefits of this kind of coding are delayed. That's a really bad use of resources for the most part. Not necessarily because those features are bad, which sometimes they are as we already discussed, that code is very often not given the attention it deserves, but mostly because we're bad at guessing what we will need. Even when we have a lot of certainty, we're bad at guessing details. And code is all about expressing the details of the features that we need. Code is as specific as it gets. And so when you're designing your code, you're doing so from the perspective that the code is an expression of an idea. But as it turns out, the code is an expression of an idea is more expensive than other expressions. It wouldn't be very hard, for example, for you to write out a plan for that multi-tenant application. It wouldn't be hard for you to draw out a visual representation of something into the future or keep track of some of the things you may want to add to the user model later down the road. Unfortunately, to implement it in code, it is significantly more overhead than simply writing it down. And here's the key factor. Inevitably, you're going to be wrong on a regular basis because, well, you're human. We make bad predictions about what we'll need in the future. So if we make bad predictions, then we build things with those bad predictions. Not only are we wasting a lot of time, but we also are creating effort that we're going to have to delete in the future. In order to remove those features out of the code base, clean them out because we needed to go a different direction. So we're not only creating very little value, but we're also adding to our work in the future just to get back to kind of a baseline. So I'll encourage you today that as you begin to look at the code you are writing, write the code you need today. Now this doesn't mean that you shouldn't refactor. Right? It's a very common problem that you take one piece of code and you say, okay, and I need to write this specific piece of code today and abstracting this. I don't need to abstract this code out. I don't need to refactor it today. I encourage you to be both vigilant about refactoring as soon as possible, as well as aware that you shouldn't be writing features that you don't need until tomorrow. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's awesome sponsor Reactor. If you're looking for a job at an awesome company doing awesome stuff, head over to Reactor.com slash careers. That's reactor with a K-REAK-TOR.com slash careers and let them know what you'd like to do in your next job. Thanks so much for listening to today's episode. If you don't want to miss out on future episodes, you know what to do. Subscribe and whatever podcasting app you are currently using right now. I'll give you a few seconds to do that. Thanks so much for listening and until next time, enjoy your tea.