My Life in Dev

However, one issue I often see around code reviews is whether they are considered as part of the in-progress state of a ticket or they are part of the completion state of a ticket. 

So here’s the thing, they are part of the in-progress state of your ticket.  When you open a code review for your changes, what most developers do is immediately go and find another ticket to work on.  This is great right! You are being busy and working effectively by implementing another change while you are “waiting” for your peers to review your code.  Well, are you?!

Let’s think about this for a second and let’s take an example.  We have a simple agile board for a mobile application project, figure 1 below.  You are assigned to the ticket - Add new Details API Endpoint Handling.  You have a colleague, let’s call them Tom, who is assigned to the ticket -  Fix Login Bug.  Tom’s ticket is currently in the review phase, you are just completing the development on your ticket. The backlog is arranged with the next priority ticket at the top in a Kanban-style. 

Figure 1

So you finish your development, you create your code review, assign a few team members to it and then mentally decide this ticket is now finished.  Tom meanwhile is still viewing his ticket as in-progress. So you pick up the next top-priority ticket from the backlog, Fix bug in Rotation handling on Details Page.  We can see this situation in Figure 2 below.

Figure 2

You begin analysing and soon after, begin implementing your new ticket.  After an hour or two, a few comments come through on your code review.  You stop what you are doing and have a read through them.  

“Oh, I’ll get to them in a while, I’m busy implementing this bug fix here,” you think.

But hang on, which ticket is nearest the customer value.  Well, your initial ticket is the nearest customer value. It obviously has more priority than the current ticket you are working on because you did it first, but now you are ignoring the completion of it because you are implementing the Fix bug in Rotation handling on Details Page ticket.  

So the priority ticket, which you have near full completion that can be merged then into your CI/CD pipeline, is now blocked because you are working on - Fix bug in Rotation handling on Details Page.  Now you are slowing down your velocity and speed to customer value. But of course, it’s all good because you are being busy!

Let’s take the other angle, let’s say the comments on your code review come in and you stop implementing - Fix bug in Rotation handling on Details Page-  and start reviewing the comments and go back working on your initial ticket - Add new Details API Endpoint Handling.  

Ok, now you’re back working on the top-priority ticket and the one nearest customer value.  That’s good. But now Tom has his Fix Login Bug ticket merged and completed and goes to pick the next top-priority ticket. 

This should be - Fix bug in Rotation handling on Details Page - but you have that in-progress, even though you aren’t doing any work on it, and so Tom picks up the next ticket in the backlog - Update User Profile Styling.
So now the situation is that Tom is working on a lower priority ticket, while the higher priority ticket you picked up is blocked while you update the implementation of the changes for your initial ticket. Figure 3 below. 

Figure 3

Ok but wait, if you don’t take a ticket while your code changes are in code review, well what do you do?!
Well, there is a myriad of things you can do. Review the code yourself as an outsider, you should always do this. Go get a coffee, take a mental break. Go do some of that training you have in your learning objectives that you tell your manager you have no time to do.  Go for a fresh air walk outside, which will rejuvenate your energy levels.

But what if no-one is picking up your code review?! Well, this is the tricky one, isn’t it? You can’t do those things for days on end equally. So here is where the team needs to recognise that when something is in code review, it needs to be a priority. It is now very near customer value, actual value. Leaving it sitting there for days is achieving nothing.  I’ve seen teams do this by having an agreed timeframe on reviewers actually getting to review the code. Of course, somedays the reviewers are stuck in meetings etc, which is why you need to choose multiple reviewers instead of relying on one person.   This needs to be recognised by the team and agreed upon by the team.  Like the professional you are, if it’s needed make sure you raise it.