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.


We need to efficiently translate customer needs and business goals into functional software features that are performant, testable and maintainable over the long term.


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.


Design PatternsReusable solutions to common problems in software design applied as needed based on the feature's requirements.Promotes code reusability, maintainability, and scalability.
API-First DesignDesigning 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 DevelopmentA 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.

  • Enables trunk based development by "hiding" work in progress features - Decouples deployment from release, allowing features to be tested in production without exposing them to all users.

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

Was this page helpful?

Wardley Mapping
© ZeroBlockers, 2024. All rights reserved.