How to tackle a software task?

We are not talking about a big project. In this article, we will talk about an average software task. Imagine you picked up a ticket from your board and assigned it to yourself, what next? That is what we will be talking about here.

Some steps overlap with the debugging process we talked about in a previous article, Debugging.

Understand the task (the requirements)

If you open the IDE and start writing code first, you will either solve the wrong problem, or you will solve the problem wrong. So the first thing to do is to read the task description and understand it well. Do not hesitate to contact the author of the task for more details and clarifications. The sooner you do that, the better.

When can you consider the task understood?

• The outcome is understood. You know why the task exists.
• You know the expectations of all stakeholders.
• You understand the acceptance criteria. You know what needs to be done to consider the task done.
• You know the edge cases.
• You notice the dependencies and blockers if they exist.
• You have a list of test cases to implement.

Understand the system

You should have a high level understanding of how the system works. You should know where every kind of component lives. Always ask for help, and don't feel guilty that you don't know.

• What is the system lifecycle?
• How is the system secured? Authorisation, authentication…
• How is the system protected? Firewalls, gateways…
• What patterns are used?
• What framework is used?
• What libraries are used?
• What does the storage look like?

Create the test cases

You have a list. Now you create the test cases one by one, and for every one you create, you write the minimum code required for the test to go green. After writing all the tests, and all of them are green, you are done with this step. You can find more about TDD in this article: Debugging With TDD.

Implement your feature

Now you really implement your logic. Your goal is to keep the tests green and the code clean.

Code review

Ask your teammate to review your code, be open to feedback, and never take it personally. They are commenting on your code, not on you. And don't feel bad if you missed a very easy and important detail. You were focusing on the problem, they are focusing on the code. Always be open to understanding why they prefer another way over yours. Never be defensive, and keep in mind that you come out smarter after every code review. If you get no feedback and an easy approval, you learn nothing. So stay open to feedback, so people don't hesitate to give you some.

How to get the best out of code review

• Add a description to your merge request that guides your team members through your solution and why you took that road.
• Write clear commit messages, so they know the context of every change.
• Keep the merge request small. How small? That depends on the context and scope, but aim for something around 200 lines of code.
• If you are in doubt about something, highlight it to the reviewers, so they give it more attention.
• Before asking for a review, make sure your merge request fulfills the definition of done. Have a checklist.

Deploy

Now you can publish your changes, after the merge request is approved and all the feedback is taken into account. Deploy that great work and monitor the production environment. Close the ticket.