3 Tips I Use When Building Features

3 Tips I Use When Building Features

Disclaimer: The tips shared in this post are based on personal experience.

I would love to start by saying features are a very important part of every software product irrespective of the platform (web, mobile, desktop, etc), and as such, they make up the pieces of what the users interact with when they use our applications.

From a business point of view, a feature can be considered as what makes a product unique from its competitors. A typical example of a feature would be a status update in WhatsApp that also allows you (the user) to share the same status on your Facebook timeline.

Now from a development point of view, features are functionalities that have corresponding benefits or sets of benefits for the user, more like the value the user gain from using the functionality. Product managers and owners are usually responsible for articulating these features and their benefits and Software Engineers are responsible for implementing (bringing it to live) the set of features.

I have built a lot of features so far in my career as a software engineer; what follows is my rudiment for building features.

Experiment (Research)

As a Software Engineer, my daily routine or responsibility is to build new features and improve on existing features implemented by other team members in the past.

When working in an agile (software development methodology) environment, the expectation of engineers is to make sure all tickets/tasks assigned to them are completed before the end of the sprint, all implemented features must work according to the requirement specified by the product manager or product owner.

Experimentation and Research are always my first step when trying to implement a new feature. In this step, I try to make sure I understand the requirement of the feature in and out, I do this by asking questions like:

  • What is the purpose of this feature?
  • What does this feature help the customer to achieve?
  • What specific challenge does this feature solve?
  • How does this feature enhance or interact with other features?

Asking these questions will help me understand clearly what is expected of the feature.

Now that I have understood the feature requirement, I'm ready to start technical implementation. Depending on the complexity of the feature, I usually start by splitting it into smaller chunks (subtasks) then I start my implementation with the most complex down to the least complex.

There's one more thing I usually do before writing the codes. If the feature is something I have implemented in the past I will most likely skip this step otherwise, I love to research the best possible way to implement the feature by studying implementations done by others.

Instead of reinventing the wheel, I look out for quality solutions already implemented in the ecosystem to leverage on, most time it might be just reviewing someone else implementation (code) to get an idea on how best it's done.

Make It Work (Functional)

At this stage, I'm ready to start writing my implementation, I do this by creatively criticizing other solutions I have studied and then writing a better version of it according to the requirement of the feature.

This is where 60% of my time is accounted for depending on how big or complex the feature is. Sometimes implementing a feature can take hours or even days depending on your experience level.

After building a piece of the entire functionality, I test it manually to make sure it's functional as expected, I also try to account for different edge cases to make sure my implementation doesn't break. I iterate (repeat) over this process until all the pieces (subtasks) of the feature are completely implemented and tested.

At this stage, I put all the pieces together to make it a complete feature and I manually test it properly with important and valid test cases that I can think of. The entire goal of this step is just to make sure the feature is working and that's the only thing that matters to me.

This is where I do the all structural dressing of the feature making sure it's looking very good, if it is a UI implementation, I'd make sure it conforms to the UI/UX design.

Commit (Code clean up and refactor)

This is always my last step when implementing a feature.

At this step, my focus is to get my implementation ready for a technical code review by other team members and my tech lead.

I am an advocate of clean and readable code so I try as much as possible to make sure that shows in my work.

I will go through the entire implementation, try to apply some programming principles like DRY, KISS, making my variable and function names meaningful, removing console.log() if there are any.

I try to make sure my implementation is not complex or difficult to read. Another important thing I do is if I'm working in a TDD (Test Driving Development) environment, I would write unit tests for my implementation and make sure existing features don't break as a result of my changes.

I often end up reading my codes 3, 4, and even 5 times. I read it until I am satisfied with the way it looks.

Lastly, when sending my PR, I try to make it as descriptive as possible, I try to explain the problem and the solution I implemented and sometimes I add some notes on some code blocks so that my reviewers will understand the reason I did what I did.

That's it!!

How do you build your features?

Does your process or technique differ from mine? I'd love to hear it!