Mastering Feature Development in Software Engineering

A Comprehensive Guide for Software Engineers

Jun 30, 2024

Preface

Imagine you're a Software Engineer-1 or 2 at a reputable company. You've efficiently completed all the small, defined tasks, bugs, and other miscellaneous work items with great velocity. Impressed by your performance, your manager decides to elevate your responsibilities by assigning you a feature to work on, albeit with a somewhat abstract and half-baked definition.

Until now, your experience has been limited to smaller projects in school and well-defined tasks at your company. While you completed school projects with passion, they often lacked a disciplined approach and were primarily aimed at securing good grades. The small tasks at your company had clear, defined goals that didn't require much additional effort on your part.

Working on a feature with a high-level goal and an abstract definition presents a new challenge, and you may find yourself wondering where to start.

To address this challenge, I've decided to write this article. My aim is to provide a structured, disciplined approach to tackling any feature in your current or future software engineering role.

In the dynamic landscape of software engineering, mastering feature development is a critical skill that can distinguish you from your peers. This comprehensive guide will navigate you through the essential stages of feature development, from initial documentation to successful execution and completion, providing you with the tools to excel in your role

In BDD, What Should Be A Feature? | Automation Panda

Feature Size

The size of the feature is crucial. Features vary in scope based on requirements and their interrelations. Typically, a feature represents one end-to-end goal of a product or service that provides value to a customer or user. Companies use different metrics to define feature size, such as sprint points or T-shirt sizing. Based on my experience, here's a rough estimate:

Small: 1-3 days
Medium: 1-2 weeks
Large: 2-4 weeks
Extra Large: 1-3 months

Note: These estimates may vary between companies and teams. It's important to understand your team's specific definitions to approach estimates accurately.

Requirement Gathering and Design Document

Requirement gathering and Design document are the backbone of successful feature development. It ensures that everyone involved in the project is on the same page and provides a reference point throughout the development cycle.

1. Feature Request and Initial Discussion

The process typically begins with a feature request from stakeholders or users. In most cases, engineering teams receive features through a Product Manager (PM), though this can vary among companies.

As an engineer, you might be involved in the initial discussions to clarify the feature's purpose and scope.

If you're not part of these initial discussions, your first step should be to ask clarifying questions about functionality, scope, use cases, personas, and other relevant aspects.

You can usually get answers to these questions from the PM, Product Owner, or Engineering Manager.

2. Creating a Design Document

Once you have good amount of clarity about feature, you can start working on a design document. Using tools like Google Docs or Quip (Whatever your company provides), create a detailed design document that includes:

Feature overview and objectives
- Aim
- Usecase
- Personas
Define scope
- What will be included in this feature?
- This can be divided into Version 1, Version 2 etc.
Define what is out of scope
- What will not be included in this feature?
- This can be future exnhancement
Assumptions
- Define all the assumtions you are taking while building this feature
- This can be resource assumption such as available memory, performance, scale etc.
Non Functional requirements (If feature demands)
- Expected scale
- Latency
- Resiliency
- Request Traffic
Detail solution
- Add UML diagrams if required (Use tools such as lucid chart or similar)
- Provide multiple options for some algorithmic and architechtural decision (With pros and cons to decide trade off)
- Always mention your recommended appraoch (That will show your decision making ability with your due dilligence)
- Most important “Keep it simple straight“
Unknowns
- Make sure you add all the unknows which you may need to dig more
User stories and acceptance criteria
- List out all the tasks
- Create user stories for each tasks and estimate size
- Write DoD (Definition of Done) criteria for all the user stories
- Ordering the user stories with priority and pre-requisite
Limitations
Potential risks (If you see any)

3. Design Review and Approval

Share the document with your team and stakeholders for review. To expedite the review process, schedule a meeting to discuss the design with your team. Remain open to feedback and be prepared to make necessary revisions until the document receives approval.

If you believe your decisions are sound, be ready to engage in factual discussions about their pros and cons. Always question and seek to understand others' perspectives by asking 'Why' instead of simply accepting their suggestions without further inquiry.

Implementation Phase

Once your design is approved, you can start working on implementation of a feature with one by one all the user stories which you created in design. This can be coding ,infrastructural changes, database, public cloud etc.

For coding, below are some basic things to follow

Follow coding standards and best practices
Write clean, maintainable code
Implement unit tests as you go
Regularly commit your changes to version control (e.g., Git)

If your team is following agile with scrum

Join daily standup
Share your progress
Discuss any blockers or challenges
Align with your team members

Code Reviews

Submit your code for review regularly and in small file chunks. This will make reviewers work easy and help them to understand better. Be open to feedback and use it as a learning opportunity to improve your skills.

Deployment & Testing Phase

Ensure your code passes all automated tests in your CI/CD (Continuous Integrtion/Continuous Deployment) pipeline. Address any issues promptly to maintain code quality.