Vox

Leitura de 15 min

Planning Series: Scaling and Detailing of Features

Summary

In this episode of Developer Tea, host Jonathan Cottrell explores a common pitfall in software development: features that start simple but become unexpectedly complex during implementation. He introduces a planning series focused on helping developers avoid scope creep and feature bloat by thinking more holistically about project requirements.

Cottrell sets up a scenario where developers sit down with clients or team members to define features, only to have one of them “blow up” later in the development process. He explains that this often happens because developers fail to ask two crucial questions during the planning phase: “how many?” and “who?” These questions help determine both the scale of what needs to be supported and the specific characteristics of the users.

The host provides concrete examples to illustrate his points. For scale, he discusses understanding how many users an application needs to support—whether it’s a global startup, a city-specific rollout, or an internal company tool. For user specifics, he examines questions like whether users understand HTML/CSS for a publishing platform or what level of translation support is needed for administrative interfaces.

Cottrell emphasizes that answering these questions preemptively—rather than during implementation or when problems arise—helps developers avoid both under-scoping and over-scoping features. He concludes by encouraging developers to understand the problem space and problem scale before beginning development work.

Topic Timeline

  • 00:00:00 — Introduction to feature scope explosion problem — Jonathan introduces the episode’s focus: why features often become unexpectedly complex despite seeming simple initially. He frames this as part of a planning series aimed at helping developers avoid common pitfalls. The goal is to discuss planning holistically rather than identifying every feature upfront.
  • 00:03:16 — Setting up the scenario of feature scope explosion — Jonathan describes a common scenario where developers define features with clients or teams, then encounter unexpected complexity during implementation. He mentions features like user sign-up and password changes as examples. The problem isn’t feature bloat but rather failing to gather the right details in advance.
  • 00:06:44 — The antidote: understanding scale and user specifics — Jonathan presents the solution to feature scope explosion: asking two key questions. First, understand scale by asking “how many?”—how many users, posts, or items need support. Second, understand user specifics by asking “who?”—what are the users’ capabilities and needs. These questions help manage complexity and eliminate assumptions.
  • 00:11:42 — Applying the framework to different scenarios — Jonathan extends the framework beyond user accounts to all application components. He uses commerce applications as an example—whether they need multi-currency support. The key is answering these questions preemptively rather than during implementation or when problems arise. Understanding problem space and scale prevents both under-scoping and over-scoping.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2017-08-30T07:00:00Z
  • Duration: 00:13:28

References

Podcast Info

Transcript

[00:00:00] Have you ever seen a feature go from what seemed to be really simple to incredibly complicated?

[00:00:12] Why does that happen?

[00:00:14] In today’s episode, we’re going to be talking about planning.

[00:00:17] This is going to be one in a series of episodes that we’re going to do.

[00:00:21] There’s probably going to be some interview episodes in between some of these, but a series

[00:00:26] of episodes that I want to do based on project planning.

[00:00:31] We aren’t going to be talking about planning in terms of identifying every single feature

[00:00:36] up front.

[00:00:37] We’re going to be talking about it more holistically in terms of what are some things that you

[00:00:43] should be thinking about when you’re planning.

[00:00:45] What are some ways to avoid pitfalls, like, for example, a feature going from what’s supposed

[00:00:52] to be a very simple feature to a really complicated feature.

[00:00:56] And really not changing much of the underlying functionality.

[00:01:00] So that’s what we’re talking about in today’s episode of Developer Tea.

[00:01:04] My name is Jonathan Cottrell.

[00:01:06] You are listening to Developer Tea.

[00:01:09] My goal on this show is to help you become a better developer.

[00:01:12] I do that by coaching you through some of this stuff.

[00:01:16] You may have never planned a project that took longer than a week.

[00:01:21] It may be your early, early days as a web developer or as a developer.

[00:01:26] It may be a native application developer.

[00:01:28] Perhaps you’ve never had the chance to deal with some of this complexity.

[00:01:34] And that’s what we’re going to be doing here.

[00:01:37] To help you become a better developer, I want to give you perspective that maybe you haven’t

[00:01:43] had the chance to gain the experience for that perspective.

[00:01:46] Or maybe you do have the perspective, but you’re forgetting some of the fundamentals

[00:01:51] or you need to be reminded of some of these things.

[00:01:54] And ultimately, you’re going to have to be a better developer.

[00:01:56] Even those of you who are very experienced, you know, you and I, if we were to sit down

[00:02:02] and have a cup of tea together, we may not necessarily agree on all of this stuff.

[00:02:07] And one of the best ways to learn is to compare our opinions, to come at the same subject

[00:02:14] and bring differing perspectives, differing opinions, different experiences from each

[00:02:20] other and compare and contrast those things.

[00:02:22] So even if you are experienced, even if you’ve planned.

[00:02:26] A hundred projects or a thousand projects before, this is still going to benefit you

[00:02:32] because us sharing our opinions together, that is one of the best ways that we can perfect

[00:02:38] the things that we do.

[00:02:39] And we’re never going to arrive.

[00:02:42] Hopefully that’s not going to hurt anybody’s feelings or disappoint any of you.

[00:02:46] You’re never going to finish getting better.

[00:02:50] That’s why the show really has no end in mind.

[00:02:54] You’re never actually going to finish getting better.

[00:02:56] You’re never going to end your learning processes.

[00:02:59] You’re never going to end your journey.

[00:03:00] This is really not about arriving as much as it is about constantly refining, constantly

[00:03:07] getting better.

[00:03:08] It’s like an equation that approaches infinity, but never quite gets there, right?

[00:03:14] So that’s what we’re talking about.

[00:03:16] We’re talking about planning and more specifically, I want to focus on this one interesting aspect

[00:03:23] of planning.

[00:03:24] I’ve run across this quite a few times.

[00:03:26] And there’s some questions that you can ask that a lot of developers forget to ask to

[00:03:32] avoid this pitfall.

[00:03:33] But I want to set up this scenario before we talk about our sponsor for the day.

[00:03:38] The scenario is you sit down with a client or perhaps you and your co-workers or investors.

[00:03:46] You sit down and you figure out a series of features to build in your application.

[00:03:53] And these features can be anything really.

[00:03:54] We want to allow.

[00:03:56] We want to allow users to sign up.

[00:03:58] We want to allow a given user to change their password, right?

[00:04:05] These are really common features.

[00:04:07] And you write all this stuff out.

[00:04:09] You figure out how much, you know, how complex each of these things are.

[00:04:13] You know, maybe you’re following the agile methodology and you think you have all the

[00:04:17] details down and then you go into actually developing the project.

[00:04:22] And one of these features just kind of blows up out of nowhere, right?

[00:04:26] What is what is the cause for this?

[00:04:28] That’s what we’re going to talk about.

[00:04:29] And I’m going to give you a few antidotes to help you avoid that feature bloat.

[00:04:35] It’s not even feature bloat, really.

[00:04:36] It’s it’s a problem with gathering the right details in advance.

[00:04:40] We’re going to talk about that right after we talk about today’s awesome sponsor, Linode.

[00:04:45] Today’s episode is sponsored by Linode.

[00:04:48] Now, I don’t have the sponsor read in front of me.

[00:04:50] And the reason for that is because Linode has been sponsoring developer T for quite a

[00:04:54] while now.

[00:04:55] So not only.

[00:04:56] Do I know these pricing numbers that are really quite good, by the way, but I also

[00:05:01] understand really the value that Linode provides to developers.

[00:05:06] And the reality is Linode has so many features beyond just providing you access to a Linux

[00:05:14] server.

[00:05:15] Linode provides you additional value that most other providers don’t have.

[00:05:21] And really, the dollar per RAM is the best in the industry.

[00:05:26] Their servers are built on solid state disks, so they’re super fast.

[00:05:31] They have a 40 gigabit internal network, so you can network multiple Linode servers together.

[00:05:37] But you also get incredible service, 24-7 service.

[00:05:42] And their plans start at just $5 a month.

[00:05:45] So you can get started very quickly with Linode.

[00:05:48] You can get a server running in just a few minutes, a couple of clicks.

[00:05:51] Of course, you can orchestrate massive, very powerful services.

[00:05:56] You can get a lot of servers on Linode with their API as well.

[00:05:58] So you could set up your system to balance across an array of servers if you wanted to.

[00:06:07] And Linode supports all of that.

[00:06:08] They have services on top of what they provide.

[00:06:11] They also have services that you can hire to help you orchestrate this stuff.

[00:06:17] So go and check it out.

[00:06:18] This is for the very entry level all the way up to the very complex needs.

[00:06:24] All of those can be mapped.

[00:06:26] Go and check it out, spec.fm.

[00:06:28] They’re going to give you $20 worth of credit today for using the code developerT2017.

[00:06:35] Thank you to Linode for sponsoring developerT.

[00:06:37] So we’re talking about why a given feature might blow up unexpectedly.

[00:06:44] We go through these processes of defining user stories, and we try to understand a feature

[00:06:49] before we get into building it.

[00:06:51] And sometimes, once we’ve built that feature and it goes live,

[00:06:54] or maybe in the process,

[00:06:56] of designing it and then translating some visual design into the actual development

[00:07:02] of that feature, something goes awry.

[00:07:05] Something explodes the scope of that particular feature.

[00:07:10] Now, I’m going to help you avoid this by giving you a few antidotes for this kind of thing.

[00:07:16] The first thing that you want to do is approach this problem,

[00:07:20] approach avoiding this problem by understanding both the scale

[00:07:25] and the specifics of your user.

[00:07:29] So what does that mean?

[00:07:31] Understanding the scale and the specifics.

[00:07:33] The scale is quite simply asking how many of this thing need to be supported.

[00:07:41] For example, how many users need to be supported?

[00:07:45] If your system allows logins, how many users are going to log into this thing?

[00:07:50] And the answer may be a range.

[00:07:52] Perhaps you are actually creating a startup.

[00:07:55] That’s intended to go and kind of be marketed to everyone.

[00:07:59] And you want there to be support for a large number of users.

[00:08:04] It may also be intended to only support a limited number of users,

[00:08:09] like, for example, an internal application at a company.

[00:08:14] And you need to understand how that number changes over time.

[00:08:17] So perhaps the application that’s intended to be marketed to everyone in the world,

[00:08:23] maybe it’s actually only going to be marketed to a few people.

[00:08:25] Maybe it’s only going to be marketed to one city to begin with

[00:08:28] and then slowly grow over time.

[00:08:30] Or maybe it’s even a smaller group, a beta testing group.

[00:08:35] And you don’t really have to necessarily build all of those features to scale right away.

[00:08:40] Here’s the reality.

[00:08:41] If you don’t gather this information, then you are building based on an assumption.

[00:08:47] You’re building based on some kind of assumption of how many users this application needs to support.

[00:08:54] Right?

[00:08:55] And we aren’t just talking about users.

[00:08:56] We’re also talking about, for example, something very simple.

[00:09:00] If you’re creating a blog, how many posts should this blog support?

[00:09:04] A lot of times we forget very simple things like pagination.

[00:09:09] And those end up biting us down the road because we didn’t set ourselves up for success

[00:09:13] by understanding what scale of things do we need to support

[00:09:17] and on what timeline do we need to support those things.

[00:09:21] A simple proof of this is,

[00:09:23] a single admin application, like, for example, a publishing application,

[00:09:29] that really only needs one or maybe two logins,

[00:09:32] well, there’s not really a good reason to create an entire user management system

[00:09:38] for that application, right?

[00:09:40] Because it’s so much more overhead to invest in that

[00:09:44] and the feature really doesn’t justify that much investment.

[00:09:48] So to avoid that feature explosion, understanding the scale,

[00:09:53] you can actually start to understand how much investment is needed

[00:09:57] for this feature to be accomplished.

[00:09:59] And on the other side of this, we mentioned understanding the specifics of your user.

[00:10:05] What kind of people are using this particular application?

[00:10:09] A very simple example, once again, is the publishing platform.

[00:10:13] You can ask a question like,

[00:10:15] does the user understand how to write HTML?

[00:10:19] Does the user have an understanding of,

[00:10:23] uh,

[00:10:23] cascading stylesheets?

[00:10:25] Can they reference an existing cascading stylesheet

[00:10:29] and write HTML into a single block?

[00:10:32] And can we trust them to be able to publish and manage that HTML?

[00:10:37] Most of the time, the answer is no.

[00:10:41] And a lot of times, we assume that the answer is no.

[00:10:44] But it’s very possible that you can avoid a lot of complexity

[00:10:48] if the answer is yes.

[00:10:50] So it’s worth asking these kinds of questions.

[00:10:53] Another question might be,

[00:10:55] what level of translation support do I need to build into the administrative interfaces of my application?

[00:11:02] These are the kinds of questions that need to be answered from

[00:11:06] understanding who is using the application.

[00:11:10] Who is this feature being built for?

[00:11:13] So, who and how many?

[00:11:15] These are two questions that actually manage your scale,

[00:11:19] they manage your complexity,

[00:11:21] they eliminate the assumptions that end you up

[00:11:24] in a position where you either

[00:11:26] underscoped the feature or you way overscoped the feature.

[00:11:30] So this is very important to understand,

[00:11:33] not only for, once again, not only for user accounts,

[00:11:36] but also for every kind of thing that your application is managing.

[00:11:42] So let’s say you’re building a commerce application.

[00:11:45] Maybe your commerce application doesn’t really need to support multiple currencies.

[00:11:49] So if you try to build multiple currencies,

[00:11:51] then from the beginning, you may be overbuilding.

[00:11:54] On the flip side, it very well may need to support every currency.

[00:11:58] What you shouldn’t do, what you can’t do,

[00:12:01] is let that question go unanswered.

[00:12:04] Don’t answer that question during implementation.

[00:12:08] And don’t answer it when it becomes a problem.

[00:12:11] Try to answer these kinds of questions preemptively.

[00:12:14] Try to understand the problem space and the problem scale.

[00:12:19] Thank you so much for listening to today’s episode.

[00:12:20] My name is Jonathan Cottrell.

[00:12:23] Once again, thank you so much to Linode for sponsoring today’s episode.

[00:12:28] With Linode, you get excellent customer service,

[00:12:31] the best dollar per gigabyte of RAM deal on the market,

[00:12:35] and a free 20 worth of their services,

[00:12:40] by going to spec.fm slash Linode

[00:12:43] and using the code DEVELOPERT2017 at checkout.

[00:12:46] That’s DEVELOPERT2017.

[00:12:49] Thank you again to Linode for sponsoring today’s episode.

[00:12:52] Thank you so much for listening.

[00:12:53] If you’re enjoying these episodes,

[00:12:55] and if you want to hear more about planning,

[00:12:57] we’re going to be doing some more episodes around this theme

[00:13:00] of planning and understanding how to prepare for a project

[00:13:04] and how to prepare during a project.

[00:13:07] If you want to hear more about this stuff,

[00:13:09] make sure you subscribe in whatever podcasting app you use.

[00:13:13] We’re going to be talking about this and many other valuable topics

[00:13:16] on this show in the future.

[00:13:17] Thank you so much for listening.

[00:13:18] And until next time, enjoy your tea.

Visão de gráfico