Things to consider while developing a feature

What is the feature?

Change in software that adds new functionality or modifies the existing functionality is called “feature” e.g Instagram reels, Whatsapp picture-in-picture mode video view, etc. 

Feature development follow SDLC phases

• Planning: Preliminary requirements analysis, research, basic project vision and scope
• Analysis: Identifying the project goals and functionality, finalizing the technical specifications, requirements and finding solutions to potentially challenging issues
• Design: Creating basic system architecture and visual design (UI/UX)
• Implementation: Software development process (Coding)
• Testing: Quality assurance process (Can be done via unit tests/ UI tests/ manual testing)
• Maintenance: Resolve if any issues get filed (from a developer perspective)

Providing estimations for the feature

The feature should be divided into several tasks and subtasks that can be easily defined and managed. Hence it becomes easier to estimate. All the tasks are then separately estimated and totaled from the bottom to the top to provide a final feature estimation.

To make a realistic estimate one should generally consider:

• Detailed specifications: The more information you have on the scope of the project and the desired outcomes the better.
• Graphic design: Complex UI elements usually require more engineering effort and take longer to implement.
• Technology stack: Depending on project specifics, the team might need to use complex tools, third-party APIs or even find custom solutions to some problems. Thus, an estimate needs to cover the research or the learning curve involved.
• The experience and personality factor: What takes a senior software engineer an hour to implement might take a trainee several days. Therefore, estimates should be tailored to the team that will work on the project.
• Buffer days: Always make sure to add few buffer days into overall estimation to handle unpredictable situations (like emergency leaves, Hardware/System issues, Delay in reviews, etc.).

Here is an example of the "Login page" feature. Following are some factors that we should consider while providing estimation for this feature:

1. What type of login should we implement (email and password login or social networks login and if yes, which ones)?
2. Should the fields have any restrictions (maximum number of characters, type of characters, password strength requirements)?
3. How should the input fields detect and handle errors (invalid email, password, etc…)?
4. Is the “Remember Me” option needed? If yes, for how long should the information be stored?
5. Which password recovery option should we use?

Code design (all about how to write a clean code)

1) Decide on the indentation and keep it that way

Style is important, not to make code look pretty, but because it helps with reading, editing, and understanding. Every developer will be more comfortable with one style or another. If you start working on code that was written by someone else, the style should be followed.

2) Make comments

There is a love and hate relationship with comments and there is a fine line between helpful comments and redundant ones. It is, in fact, very useful to use them to explain the code, especially complicated passages. It may seem obvious to you when you are writing it, but will others who work on the code understand it? Will you remember what you did after a month or a year?

Comments are worthwhile as long as they are a few and written for key passages. Too many comments at every single line will make the code completely unreadable and messy, no matter how neat the style and consistent the indentation.

3) Don’t repeat code

Repeating code will make your document very long and it will break the reading flow. If you have pieces of code that will be used more than once, it is preferable to make a separate file or a method.

4) Avoid writing long code lines

Writing long lines of code makes it very difficult to read, moving back and forth horizontally, losing any sense of what it’s actually written. Style and indentation will help with this.

5) Break down a big task into smaller chunks

A whole new feature will never be just a few lines long. Even with comments, a 500-lines function will still be a pain to browse, understand and edit. Your best choice is to break down the big task into a smaller chunk of code.

6) Organize your program into smaller files

Having a file with thousands of lines of code doesn’t help anyone, but broken down into shorter files organized based on function or feature will help you get right to the point when something needs fixing. Having the whole code organized in files and folders is very good for maintainability, especially if different teams and people are working on it.

7) Use Design Patterns (MVP, MVVM, etc.)

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

Unit + Manual testing of the feature

Feature testing ensures that the newly developed feature has no bugs and works as expected. The focus is to make sure that the product delivered to the client and end-user has no issues. Testing of the developed or modified feature is very important as any issue found in the existing functionality because of the new features can create a lot of problems.

Unit testing:

The unit test ensures that individual code i.e. small piece of code works fine. Unit Test is done whenever a new class is written, any bug is fixed, or any functionality is changed.

Manual Testing:

Always test from the end-user perspective like background-foreground scneario, Wifi off scenario, screen orientation change, request sent and app killed, different API levels etc.

Feature flags

New features can be deployed without making them visible to users. Feature flags help decouple deployment from release letting you manage the full lifecycle of a feature.

Feature flags go by many names:

1. Feature toggle
2. Feature flipper
3. Conditional feature

Feature flags eliminate the need to maintain multiple feature branches within your source code. All code changes can be made to the primary branch, only when the feature is ready will it be enabled via the flag.

Track deadlines

• Double-check estimations on a timely basis to understand whether the progress is going as per the estimation and we will complete the feature within the deadline.
• If any spikes are observed, find solutions/alternate approaches to handle it (like adding more resources) else alert clients about the delay early.
• If causing delay due to runtime requirements changed then re-estimate and alert client regarding new estimations to maintain trust.

Basic checklist (which I follow while developing a feature):

1. Do we have any questions on feature requirements?
2. Do we have feature flags?
3. Do we have the required UX specifications, strings to be used for the feature?
4. Do we know the key persons for the feature (tech lead, reviewers, UX persons, testers, managers etc.)?
5. Are we providing client updates in a timely manner to maintain trust?

This is all about feature development that I learned in my career path. I hope this information will be useful for those who work on features. Thanks for reading and keep learning :-)