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 have talked about in the previous article Debugging.

Understand the task (The requirements)

Opening the IDE and starting 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.

What to expect to have to consider the task understood?

• Outcome is understood. You know why the task does exist.
• You know the expectation 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.
• 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 exist. Always ask for help, and dont feel guilty that you do not know.

• What is the system lifecycle?
• How the system is secured? Like authorisation, authentication…
• How the system is 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, write the minimum code required for the test to go green. After writing all tests, and all are green you are done with this step. more information about TDD can be found in this article Debugging With TDD

Implement your feature

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

Code review

Ask your teammate to review your code, and be open for 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. Be always open to understand why they prefer another way over yours. Never be defensive, keep in mind that you come out smarter after every code review. If no feedback given on a code review, and you got an easy approval, you learn nothing. So keep yourself open for feedback so people do not hesitate giving you one.

How to get the best of code review

• Add description to your merge request that guide your team members over your solution and why you took that road.
• Have a 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 of something, highlight that to the reviewers, so they give it more attention.
• Before asking for a review, make sure your merge request fulfills the definition of done, so have a checklist.

Deploy

Now you can publish your changes after it gets approved and all feedback are taken into account. Just deploy that great work and monitor the production environment. Close the ticket.

If you have any questions, suggestions, or you are seeking help, don't hesitate to get in touch with me on Twitter at @salem_hsn