Designing the Feature
Designing a feature involves the process of planning and specifying the details of a software feature, including its functionality, user interface, and integration with the existing system.
Purpose
We need to efficiently translate customer needs and business goals into functional software features that are performant, testable and maintainable over the long term.
Context
Industry Context
Most features fail to deliver the expected value. We need to enable iterative delivery of features so we can get feedback from users and adjust the features to meet their needs.
ZeroBlockers Context
Teams are accountable for outcomes so they need to ensure that the features they build meet the current needs of the users and the business as well as ensuring that they are maintainable and scalable so that they do not slow down future development.
Practices
| Practice | Description | Benefits | ||
|---|---|---|---|---|
| Design Patterns | Reusable solutions to common problems in software design applied as needed based on the feature's requirements. | Promotes code reusability, maintainability, and scalability. | ||
| API-First Design | Designing the API interfaces before implementing the functionality they expose. | Clear contract definition between different parts of the system | ||
| Test-Driven Development (TDD) | Writing tests before code to specify and validate what the code will do. | Ensures code meets requirements before implementation, leading to fewer bugs. | ||
| Acceptance Test-Driven Development (ATDD) | Writing tests that define the expected behaviour of the feature before development begins. | Aligns the team on feature expectations and reduces misunderstandings. | ||
| Trunk Based Development | A source-control branching model where developers collaborate on a single branch, promoting continuous integration and reducing merge conflicts. | Reduces integration issues and enables faster feedback loops. | ||
| Implementing Feature Toggles | Allows teams to merge features into the main branch even before they are completed and ready for release. |
| ||
| Big Ball of Mud: A haphazardly structured system that lacks a perceivable architecture, making it difficult to maintain and extend. | Overengineering: Adding unnecessary complexity to the architecture, including features or layers that are not required, making the system harder to understand and maintain. | Cargo Cult Programming: Blindly following practices, patterns, or tools without understanding their purposes or considering the context, leading to inappropriate or ineffective solutions. | Not Invented Here (NIH) Syndrome: Rejecting external solutions in favour of internally developed solutions, even when the external solutions are more efficient or suitable. | Ivory Tower Architecture: Designing the architecture without considering practical constraints or the input of the development team, leading to a disconnect between design and implementation. |
Case Studies
Unlocking Efficiency in Feature Development with Feature Toggles
How Spotify improved its feature development process by implementing feature toggles, enabling data-driven product development.
Spotify
Boosting Business Performance with Test Driven Development
How ASOS improved its business performance by integrating Test Driven Development (TDD) into its software development processes.
ASOS
