Task and check-in sizes

Task escalation and large shelf-sets is something which we've all encountered at one point or another. As developers we have a tendency to get into a task and just keep writing code until it is finished, without ever taking a moment to step back and see if there is a more modular approach we can adopt.

There are several reasons why we should be aware of this situation and take steps to mitigate it.

1. Think of the reviewer! I was asked to review a new chart for WIT. The development had started a couple of months earlier and by the time it got to review there were 51 files in the changeset.

Attempting to review a changeset of this size and complexity is very difficult and very time consuming. The biggest problem with this is the complexity and expecting the reviewer to be able to keep track of all the changes you've made, their implications and anything you might have missed. It is simply too big to be reviewed with any confidence.

2. Merge hell. The longer you go without checking your work into the depot, the more likely you are to encounter merge issues when you finally come to check it in. When you get merge issues, in the best case you need to work out what additional testing you need to perform. In the worst case you have to rewrite some of your change to accommodate changes made by someone else.

So, what can we do to mitigate these problems? Well, essentially things we should be doing anyway: plan and design your change before you start writing any code. Before you start writing any code, you should have a clear idea of all of the changes required. To mitigate the risk of producing giant changesets, simply look at the list of changes required and break it down into manageable chunks.

For example, consider the changeset shown above to add a new chart to the executive summary in WIT. Rather than create a single task titled "Create Chart" as happened in this case, think about the steps involved in generating a chart:

1. Get the chart data out of the cube
2. Update the domain logic to determine if we need to get the chart data for this chart
3. Update the application logic to handle a request for this chart
4. Update the UI to request and display this chart

Each of these tasks could be tackled in isolation. Some of them can even be done independently meaning you would not end up waiting for a previous changeset to be reviewed.

Probably the easiest way for you to monitor this for yourselves is to impose a maximum time between check-ins. I would say that you should be aiming to check something in twice a day and should definitely be committing something once a day.

With splitting tasks down there is of course a danger that you will end up waiting for something to be reviewed before you can carry on with a particular task. If everyone is following this practice, and you get into the habit of actioning all review requests when you submit a piece of work, then we should have plenty of throughput on the reviews minimising any hold ups.