Vox

Leitura de 14 min

Future Features (Are Futile)

Summary

In this episode, host Jonathan Cottrell explores a common but problematic practice in software development: building code to accommodate features that might be needed in the future. He identifies this as a conceptual “code smell” that often stems from business objectives or a desire for flexibility. The episode argues that this approach is usually counterproductive.

Cottrell provides concrete examples, such as over-engineering a sales tax system to handle multiple states or countries before it’s necessary, prematurely architecting for multi-tenancy (white-labeling), or adding numerous optional fields to a user model in anticipation of future needs. He explains that this “future feature” code often becomes a second-class citizen: it’s unfinished, poorly tested, complicates the codebase, and diverts attention from current priorities.

The core problem, as outlined, is that developers are inherently bad at predicting future needs in detail. Writing code is a high-overhead way to express these guesses, much more costly than simply documenting ideas. Since predictions are often wrong, this practice not only wastes immediate effort but also creates future work to remove or rework the misguided code. The delayed benefits rarely justify the upfront cost.

The episode concludes with a clear, actionable principle: “write the code you need today.” Cottrell clarifies that this does not mean avoiding necessary refactoring of existing code to improve clarity or structure. Instead, it’s a warning against implementing features or foundational structures for requirements that do not yet exist. The key is to be vigilant about refactoring current code while resisting the temptation to build for hypothetical tomorrows.

Recommendations

Companies

  • Reaktor — A digital product studio in New York City (spelled with a ‘K’ due to Finnish heritage) that designs and builds products for clients like HBO, Supercell, Viacom, and Finnair. They are hiring software engineers and encourage applicants to describe their dream role rather than applying to a predefined job description.

Topic Timeline

  • 00:00:23 — Introducing the conceptual code smell of future features — Jonathan introduces the episode’s topic: a code smell related to building for future business objectives. He explains it’s something developers often do, sometimes unconsciously, especially when they have high confidence in business decisions. The episode will explore why this practice is problematic.
  • 00:01:47 — Examples of future feature development: sales tax and multi-tenancy — The host provides the first major example: over-engineering a sales tax system for multiple states or international use before it’s needed. He then gives a second example: building for multi-tenancy or white-labeling out of fear of future inflexibility. He notes that this approach can be painful and promises to explain why after a sponsor message.
  • 00:05:31 — Why building for future features causes trouble — Returning from the sponsor segment, Jonathan explains why preparing for future features gets developers into trouble. He provides a third common example: adding excessive fields to a user account model. He details the problems: the code is often unfinished, becomes a second-class citizen with poor test coverage, and unnecessarily complicates the system for needs that may be years away.
  • 00:07:41 — The core problem: we are bad at guessing future needs — Cottrell identifies the fundamental issue: developers are bad at guessing what will be needed, even with high certainty. Code is about specific details, and our predictions about those details are often wrong. Implementing guesses in code is far more expensive than other forms of expression (like writing a plan), and being wrong means wasting time and creating future cleanup work.
  • 00:09:24 — The principle: Write the code you need today — The host delivers the core advice: write the code you need today. He clarifies that this does not mean avoiding refactoring; developers should be vigilant about refactoring existing code for clarity. The key distinction is between refactoring current code and implementing entirely new features or structures for hypothetical future requirements.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-08-01T09:00:00Z
  • Duration: 00:10:48

References

Podcast Info

Transcript

[00:00:00] What code do you need today?

[00:00:08] That’s what we’re talking about on today’s episode of Developer Tea.

[00:00:12] My name is Jonathan Cottrell and you’re listening to Developer Tea.

[00:00:15] My goal on the show is to help driven developers connect to their career purpose

[00:00:18] and to help them do better work so they can have a positive influence on the people around them.

[00:00:23] In today’s episode, we’re talking about a particular code smell.

[00:00:27] This episode and next episode are going to be about code smells.

[00:00:30] But this is a more conceptual code smell.

[00:00:33] It happens as a result very often of a business kind of objective that we translate into our code.

[00:00:42] And I want to talk about it because I think it’s something we all do.

[00:00:45] And sometimes we do it without even realizing it.

[00:00:48] Sometimes we incorporate this stuff because we really have a high level of confidence in our business decisions.

[00:00:56] This isn’t a bad thing.

[00:00:59] If you work, for example, on behalf of a business owner,

[00:01:04] let’s say you are a freelancer or you are an individual contributor developer

[00:01:08] and you are not the person that’s making the business level decisions.

[00:01:13] Where is this product going to go?

[00:01:15] The product ownership decisions and the product management decisions.

[00:01:19] You’re not making these decisions.

[00:01:21] And so you as the developer, you are receiving some information.

[00:01:26] And of course, in a healthy team, you’re collaborating about this information.

[00:01:29] You’re trying to provide the reasonable technical information

[00:01:35] to help those people make good decisions based on their resources.

[00:01:41] And as you’re implementing this code for the feature that is being asked for,

[00:01:47] you’re realizing that this is the place that a future feature,

[00:01:54] say that five times fast,

[00:01:56] future feature is likely to show up.

[00:01:59] For example, let’s say you are working on some kind of shopping cart

[00:02:02] and you maybe you’re living in the United States.

[00:02:06] You’re implementing sales tax for the state that the company is operating in,

[00:02:11] especially if this is a physical location for this particular business.

[00:02:17] And so instead of implementing for just that state,

[00:02:20] you start to think, OK, I should probably implement sales tax for other states as well.

[00:02:26] And then you implement sales tax for other states.

[00:02:30] But in order to do that, you have to create the concept of multiple states.

[00:02:35] And while you’re at it, maybe go ahead and create some kind of international

[00:02:39] way of dealing with things, whether that’s sales tax,

[00:02:45] or maybe you start thinking that you should start creating shipping costs,

[00:02:50] shipping estimates.

[00:02:51] And so you start building out the structure, even the kind of the foundation,

[00:02:56] even if you aren’t necessarily building it all the way out.

[00:02:59] You’re building these foundational things for features that are going to be added in the future,

[00:03:07] or at least that’s what you expect.

[00:03:09] You expect those features to come into the future.

[00:03:12] Another example of this, let’s say that you’re building an application

[00:03:15] and you expect, or at least you suspect,

[00:03:19] that the application is going to be white labeled,

[00:03:22] that it’s going to be multi-tenant, right?

[00:03:24] In other words,

[00:03:26] you’re going from one to many, let’s say,

[00:03:29] domains that it’s going to live on, for example.

[00:03:33] And so out of the fear of being inflexible later,

[00:03:36] you try to build this system with flexibility on day one.

[00:03:40] Now, if you’ve been in this place,

[00:03:42] you probably know that it can be painful.

[00:03:44] And we’re going to talk about why in just a moment,

[00:03:47] right after we talk about today’s sponsor, Reactor.

[00:03:49] Reactor is a digital product studio in New York City,

[00:03:52] designing and building products and services for forward-thinking businesses

[00:03:56] and organizations.

[00:03:57] By the way, Reactor is spelled with a K,

[00:04:00] and that’s because the Finnish language doesn’t use the letter C.

[00:04:04] That’s R-E-A-K-T-O-R.

[00:04:07] And they take this Finnish heritage really quite seriously.

[00:04:11] Relationship is a high priority for the people at Reactor,

[00:04:15] but not at the expense of work.

[00:04:18] They’ve partnered with people like HBO and Supercell and Viacom,

[00:04:23] even Finnair.

[00:04:24] They designed and built,

[00:04:26] the digital customer journey for Finnair,

[00:04:28] including their onboard experience.

[00:04:31] Finnair is the Finnish airline, by the way.

[00:04:35] So they’re developing their own satellite

[00:04:38] to explore emerging new space business opportunities.

[00:04:42] That’s new space business opportunities,

[00:04:46] like opportunities in space for business,

[00:04:49] from hardware to rethinking putting code into space.

[00:04:52] This is literally launching into orbit later in 2018.

[00:04:55] So,

[00:04:56] we’re telling you all about Reactor

[00:04:57] because Reactor is hiring.

[00:04:59] They’re looking for great software engineers

[00:05:00] for a number of product roles

[00:05:02] with different emphasis on the wide context

[00:05:06] of product development.

[00:05:07] Instead of predefining the position, though,

[00:05:10] they’re not going to give you a job description.

[00:05:12] Instead, they want you to reach out

[00:05:14] and explain what your skills are,

[00:05:16] explain what your experience is,

[00:05:18] your ambitions,

[00:05:19] and ultimately your dream role.

[00:05:21] Head over to Reactor.com.

[00:05:22] Remember, that’s R-E-A-K-T-O-R.com.

[00:05:26] Thanks again to Reactor

[00:05:28] for sponsoring today’s episode of Developer Tea.

[00:05:31] So we’re talking about why this future feature development

[00:05:37] or even preparing for these future features,

[00:05:41] why this can get us in trouble.

[00:05:43] I’ll give you one more example.

[00:05:45] So maybe if you didn’t connect with the other two examples,

[00:05:48] maybe you will with this one.

[00:05:49] This happens very often with user account information.

[00:05:53] We try to add a lot of fields

[00:05:55] that we may want to track in the future.

[00:05:58] We had first and last name and email,

[00:06:00] and that may be enough for our launch,

[00:06:03] but we want to carry that forward.

[00:06:05] We add the zip code

[00:06:06] and perhaps a whole slew of other fields.

[00:06:10] Now, this doesn’t necessarily create

[00:06:12] a lot of technical debt per se,

[00:06:15] but often what ends up happening

[00:06:17] is we start tripping over this code

[00:06:20] for a couple of reasons.

[00:06:22] One, often this code goes unfinished

[00:06:24] because,

[00:06:25] it isn’t really needed.

[00:06:28] It’s kind of in the way

[00:06:29] and it wasn’t really prioritized.

[00:06:31] So very often this code

[00:06:33] only gets some of our attention.

[00:06:36] Sometimes placeholders are put into place

[00:06:38] and they aren’t really doing anything.

[00:06:40] The test coverage is often poor.

[00:06:43] And certainly the interface

[00:06:44] isn’t really reflecting those features.

[00:06:47] And so we have these kind of

[00:06:49] second class citizens in our code.

[00:06:53] Sometimes those second class citizens

[00:06:55] also require us to make our code

[00:06:57] more complicated than it needs to be.

[00:06:59] In the example where we need to support

[00:07:01] multiple tenants,

[00:07:03] maybe we don’t really need to support

[00:07:04] multiple tenants for a few years

[00:07:06] in the product that we’re building.

[00:07:08] And so we’re having to go through

[00:07:10] all of the technical work

[00:07:12] to support tenants today

[00:07:13] that ultimately wouldn’t be all that hard

[00:07:16] when we are scaled up

[00:07:18] and we really need it.

[00:07:20] The benefits of this kind of coding

[00:07:22] are delayed.

[00:07:23] That’s a really bad use of,

[00:07:25] of resources for the most part.

[00:07:27] Not necessarily because

[00:07:29] those features are bad,

[00:07:32] which sometimes they are,

[00:07:33] as we already discussed,

[00:07:35] that code is very often

[00:07:36] not given the attention it deserves,

[00:07:39] but mostly because we’re bad at guessing

[00:07:41] what we will need.

[00:07:43] Even when we have a lot of certainty,

[00:07:46] we’re bad at guessing details.

[00:07:48] And code is all about expressing

[00:07:51] the details of the features that we need.

[00:07:55] Code is as specific as it gets.

[00:07:58] And so when you’re designing your code,

[00:08:01] you’re doing so from the perspective

[00:08:03] that the code is an expression of an idea.

[00:08:07] But as it turns out,

[00:08:08] the code is an expression of an idea

[00:08:10] is more expensive than other expressions.

[00:08:15] It wouldn’t be very hard, for example,

[00:08:17] for you to write out a plan

[00:08:19] for that multi-tenant application, right?

[00:08:22] It wouldn’t be hard for you to draw

[00:08:25] out a visual representation of something

[00:08:28] into the future or keep track of

[00:08:30] some of the things you may want to add

[00:08:31] to the user model later down the road.

[00:08:34] Unfortunately, to implement it in code,

[00:08:37] it is significantly more overhead

[00:08:39] than simply writing it down.

[00:08:42] And here’s the key factor.

[00:08:43] Inevitably, you’re going to be wrong

[00:08:46] on a regular basis because,

[00:08:47] well, you’re human.

[00:08:49] We make bad predictions about

[00:08:50] what we’ll need in the future.

[00:08:52] And so if we make bad predictions,

[00:08:54] then we build up the idea that we’re wrong.

[00:08:55] And so we build up the idea that we’re wrong.

[00:08:55] And so we build up the idea that we’re wrong.

[00:08:55] And so we build up the idea that we’re wrong.

[00:08:55] And so we build things with those bad predictions.

[00:08:57] Not only are we wasting a lot of time,

[00:08:59] but we also are creating effort

[00:09:02] that we’re going to have to delete

[00:09:04] in the future.

[00:09:06] In order to remove those features

[00:09:08] out of the code base,

[00:09:10] clean them out because we needed

[00:09:12] to go a different direction.

[00:09:13] So we’re not only creating very little value,

[00:09:17] but we’re also adding to our work

[00:09:19] in the future

[00:09:20] just to get back to kind of a baseline.

[00:09:24] So I’ll encourage you today

[00:09:25] that as you begin to look at the code

[00:09:28] you are writing,

[00:09:29] write the code you need today.

[00:09:33] Now this doesn’t mean

[00:09:34] that you shouldn’t refactor.

[00:09:36] It’s a very common problem

[00:09:38] that you take one piece of code

[00:09:41] and you say, okay,

[00:09:41] I need to write this specific piece of code today.

[00:09:44] And abstracting this,

[00:09:45] I don’t need to abstract this code out.

[00:09:48] I don’t need to refactor it today.

[00:09:50] I encourage you to be

[00:09:52] both vigilant about refactoring

[00:09:54] and refactor it today.

[00:09:55] As soon as possible.

[00:09:57] As well as

[00:09:58] aware that you shouldn’t be

[00:10:01] writing features that you don’t need

[00:10:03] until tomorrow.

[00:10:05] Thank you so much for listening

[00:10:07] to today’s episode of Developer Tea.

[00:10:09] Thank you again to today’s awesome sponsor, Reactor.

[00:10:11] If you’re looking for a job

[00:10:13] at an awesome company doing awesome stuff,

[00:10:15] head over to Reactor.com

[00:10:17] slash careers. That’s Reactor with a K.

[00:10:19] R-E-A-K-T-O-R

[00:10:21] dot com slash careers.

[00:10:22] And let them know what you’d like to do

[00:10:24] in your next job.

[00:10:26] Thanks so much for listening to today’s episode.

[00:10:28] If you don’t want to miss out on future episodes,

[00:10:30] you know what to do.

[00:10:31] Subscribe in whatever podcasting app

[00:10:33] you are currently using right now.

[00:10:35] I’ll give you a few seconds to do that.

[00:10:38] Thanks so much for listening

[00:10:39] and until next time, enjoy your tea.

Visão de gráfico