How to slice a feature
Strategies for breaking down complex features into manageable tasks
Quite often, we find ourselves needing to break down a feature into smaller parts so that they fit within a certain time frame. How can we approach this?
Trimming functionality
The first and most obvious approach is to trim functionality. But the key question is, which functionality should be trimmed? From a team leader's perspective, we should trim the functionalities that are least important from a business standpoint.
Unfortunately, this often leads to trimming: tests, documentation, monitoring, or security. These are crucial elements that ensure quality. This is where a staff+ engineer should step in and at least protest.
Of course, a one-time trimming of these elements might be acceptable, but if it happens regularly, it's worth analyzing why this is happening. In a world of advanced IDEs, AI, and software development automation, ensuring quality shouldn't be a problem. A few examples:
If developers have trouble writing tests, there's probably something wrong with our code structure.
If there's no time for documentation, we probably don't have a good software development process.
If there's no time for monitoring, there's probably something wrong with DevOps or the platform.
It's worth paying attention to small symptoms, as over time, they often lead to big problems.
Breaking down into smaller parts
The second approach is breaking down into smaller parts. It's worth noting that this isn't always possible, and even if it is, as technical people, we often have the temptation to make a horizontal slice. This means breaking down into smaller parts that are theoretically independent but push the project forward.
In practice, it turns out that we have, for example, ready tables in the database, which give us no business value. A much better idea would be to design an API that other teams can use.
Note: this doesn't mean that designing a database is always bad and an API is better. It depends a lot on the usage and context of the project.
The question is, what pushes the project forward? In large organizations, it often turns out that we can also make a horizontal split in terms of production deployment, i.e., we accept a process split, not a technical one.
Vertical slicing
What is a vertical slicing? It's a technique that involves breaking down functionality into smaller independent parts. We can implement them independently, and they should provide business value. On the other hand, when we start applying this to business features, it often turns out that we don't see the point in such a split.
As an example, let's take the migration of a database structure. We can break it down into several parts:
Changing the database structure
Changing the application code, i.e., API, tests, documentation, monitoring
Writing a migrator and performing data migration
If we look at it from the system's perspective, the argument might be: until we change the structure, code, and migrate the data, it's hard to talk about any value. However, we can approach it differently:
First, we change the structure, write the migrator, and perform the migration - after this step, we can verify if our structure is good by running performance test simulations and ensuring it's better. The business justification is simple: we have confirmation that after the migration, it will be better.
In the second step, we make the rest of the changes, i.e., change the application code.
Of course, such a split isn't free. It requires us to think about how to do it, especially from a technical point of view. Again, as staff+, we return to the question: what pushes the project forward?
Summary
There's no one right way to split features. It's often worth mixing different approaches. As staff+ engineers, we should be able to understand the business and technical context and propose a split that makes sense and brings value. Even if that value is reducing risk or enabling further work for others.