As software engineers, we always face a problem on how to break a task down to independent release ready parts before writing code. It is also a shared responsibility of the project manager to jot down optimally small and independent tasks/tickets. But, it is not what we get especially if the product is new and has not been released to production. In my experience, having this language and framework agnostic skill will help you become a senior and better software engineer.

Sometimes the task description is a one-liner which you can interpret to anything of your liking. So, this post will help you solve this issue, where given a task how do you plan to split it into independent release ready parts. Regardless of the language and framework, software design and architecture play an important role in the life of your software, a strong base is needed to build a software system that will last longer.

Some Assumptions

For this post following are the assumptions:

1. A project management system like JIRA/Redmine/Trello is used where tasks are defined as tickets/cards.
2. A Version Control System (VCS) is being used for the project you are working for.
3. There is a team structure in place, where if you are the software engineer there is a team lead above you.
4. Possibly your team follows the Agile software development methodology

How to split that feature

As an example, let's take Project X with project code PX as the project you are working on. And you are assigned the task PX-4 to develop/code the user system (users are ubiquitous to every software system) that has the following contents:

Title: Develop a user system for the back-end
Description: Users should be able to create, view, edit and delete other users in the system.

Now after you are ready to do this task what should your next step be? Jump on your desk start writing code? Surely not.

You need to organize and discuss each of your tasks and have a mindset to split it into independent release ready tasks first in your mind and best document it on something.

So how do you do it then?

Think CRUD

CRUD — Create Read Update Delete is in the given sequence because in my opinion when you start writing code for a new feature you should do each step one after the other in that sequence.

As an analogy, its like if you are given a block of unsliced bread you don’t start biting pieces off it. You first cut it into slices of the right thickness and then eat the slices one after the other.

Same goes when you write code for a feature. In relation to the user system for the backend, think in terms that you will first finish the create user and show user parts then only approach the edit and delete segments.

The same technique can be ported to an API development scenario where you will do the POST first, then do the GET after which PUT and DELETE can follow. You can easily test it with curl and see that your POST is persisting data the database table and your GET responds with the correct data in the desired format. Same can be followed for PUT and DELETE.

Scope it and outline steps to solve it

This is important, you need to have a scope defined for the task and you need to write down how you are going to write code to complete the task.

It is best to discuss your scope and steps to the solution with your team lead, communication is always important for software engineers.

You can care less about non-functional requirements still it has to be agreed upon with your lead developer. As an example I have added a gist in markdown that outlines the scope and steps to the solution of the PX-4 user system for the backed, it included below as well.

## Scope and steps for user system ticket - PX-4

### Proposed steps to develop the ticket:

1. Add new table to the main db users table, with needed columns (id, email, password, first_name, last_name, restore_key, created_at, updated_at) 
  1. Add a migration for the columns mentioned above
  2. Tests the migration on local and also record the time it takes to run locally.
2. Add form to create new user and make persist it in the db table. Password will be encrypted using SHA512.
  1. Do basic validation like required
  2. Enhance validation to accept only email in email field, accept only alphabets (not numbers) for first name and last name. 
3. List users in a [master detail](https://en.wikipedia.org/wiki/Master%E2%80%93detail_interface) tabular format
  1. Create the listing page with id, email, first name, last name, created at, actions column as row for each user
  2. Create the detail page with id, email, first name, last name, created at, updated at in a detail table format
  3. Add pagination to users with fixed 10 users per page
4. Edit users with the same form and validation as create, will update only one user
  1. Add edit link in the users listing page
  2. Adjust validation to make password optional
  3. Passwords will be updated only if provided, if empty old password will not be changed
5. Delete user will delete single user from db
  1. Add delete link in the user listing page and delete button in the user detail page, both should confirm before deleting
  2. After deleting from user detail page, user will be redirected to user listing page with a flash message on top

### Other consideration

1. User will not be able to delete self
2. Roles are not taken into consideration for this ticket, it is part of PX-7
3. Front end user login and registration is part of PX-8

So the task is divided into 5 major parts and each part has 2–3 subparts, this gives you a clear sense of what needs to be done. Now, you can estimate each subpart which adds up to the total estimation of the whole task. Though you might have the urge to develop the login and registration part, you need to stop yourself and focus on the scope to meet the estimation provided. The focus is necessary for the task to be completed well.

Independent release ready parts

As outlined above, you should then subgroup the tasks to independent release ready parts. What do you consider release ready will depend on many factors like:

• Is the project already in production?
• How many people are using it?
• Is there a feature switch that can turn the feature on or off? (like with a cookie or email address)

Thereby, you will again need to discuss this with your lead on what can be considered release ready. Let's say for our example user system task PX-4 the discussion ended on the understanding that as the project is not released to the public so the independent tasks are:

1. Create user and view the user is functional with validation (Points 1,2 and 3 in the gist)

2. Update and delete can be done in next increment (Points 3 and 4 in the gist)

For your own work as a software engineer, if you write tests then it is best to write a test for each main point in the task breakdown. If you do test driven development then you will write tests first, if you do test supported development make it a habit to write tests for each task after completing it than piling up all the tests at the end. This which will save you time too.

Push each day and communicate

With an assumption that git is being used for the project, it is highly recommended that you push each day end. Communication is always key to success, so as per need you may need to update your team and team lead on the progress. If your team follows scrum and has a daily stand up meeting it will be easier to update on what you have done as the big task is organized in a way where it is easy to track progress.

Conclusion

Only coding a feature does not complete the task, you need to test it very well on staging and if the project is deployed on production the testing needs to be done well on production too.

It is a very good practice to commit early, commit often, in case you have a continuous integration set up you will get feedback early on the whole test suite. It is also advised to follow release early release often, this is possible if you are able to complete the independent release ready parts with less/no problems. Then you can release in increments as you wrote the feature in increments. Checking the code and as per need refactoring your code for the feature is also essential.

I hope after all this our example backend user system task PX-4 is deployed using an automated deployment without problems on the desired environment. The task is well tested and no further issues are reported for the task. It is time to close the task and continue practicing this new skill you learned to first split a given task into independent release ready subparts. Good Luck!

Originally published at geshan.com.np.