Don't Place Unfinished Work On A Queue

Never start work on an item if we cannot deliver it without interruptions

Any time I join a new team of software developers, I am noticing one interesting phenomenon — the team is carrying a lot of unfinished work. Even a cursory glance at the team's code repository (or repositories) almost always reveals a surprisingly large number of branches. Each branch represents some unfinished work. It is also very easy to spot stale branches, and the majority of branches are typically stale (meaning, more than a month old; sometimes more than a year old — yikes!)

What’s also interesting is how very few software professionals think that something is not right about that situation. The majority seem to feel that it is perfectly okay to squirrel away and place on some shelf dozens and sometimes even hundreds of stale branches. Of course, every now and then you meet an experienced, competent developer who would complain about such a state of affairs. But in my experience, such people are few and in between (sadly).

Why is unfinished work bad? Frankly, I still get surprised whenever someone asks me that question. Not being aware that unfinished work is bad bellies the lack of awareness of the cost of running a software development department. Any time that we spend working on some source code costs our clients/employers some real money. If that work then gets shelved, it means that we have wasted their money. And that type of behaviour is not professional. Not in the least.

What’s the remedy?

OK, Alex, it is easy to criticize others. But do you have a solution for this issue that’s causing teams to waste people’s money?

Glad you asked! Let me start by saying that there is a solution, but gosh, it ain’t easy to implement it. But hey, that’s why they pay us the big bucks — to find solutions to hairy problems.

On to the solution: it may be a multipart solution, and, as I mentioned, it won’t be easy to get it to work. In a nutshell (and this is the toughest part), the best approach is to make sure we don’t start to work on something if we are not certain that we will be able to finish it without placing it on any waiting list/queue. So, no interruptions to the workflow. What that means is that the secret sauce is to avoid having half-baked/half-finished work sitting somewhere on the shelf. Never let yourself get there.

Why is half-baked work that is placed on a waiting list/queue such a bad situation? For starters, and as we already mentioned, it’s not money well spent. But perhaps even worse than that, when we abandon an item we are working on by placing it on some queue, we put ourselves in the position to start working on something else. And chances are that something else will also end up sitting in some other queue in a half-baked state.

You see where we are going with this. As the waiting queues start bloating, that predicament creates a series of traffic jams, or log jams. It takes many orders of magnitude more effort to unjam one queue than it takes to actually finish the work item and deliver it to customers. But imagine having not one but many such waiting queues that keep bloating. Now we’re juggling many balls in the air, and that is certain to bring our organization to its knees.

To avoid creating those pesky waiting queues, we must arrange our work environment in such a way to make sure that once we start working on some item, we do not stop until that item gets delivered to production and into customers’ hands. Of course, that is easier said than done. Many everyday incidents of being forced to place some half-finished item in a waiting queue are caused by the dependencies. Dependencies such as waiting on some other items to be completed before we could complete the work on our item.

That may sound like an insurmountable issue, but keeping in mind that we are trained engineers, it is our duty to experiment and innovate and find solutions for this seemingly insurmountable problem. Let’s start with the decision to never begin the work on a new item if we’re not very sure that we will be able to deliver it without having to place it in a waiting queue. Having that orientation will help us identify real bottlenecks. Once we see the real bottlenecks, we’ll know what to do next.

Have you been in the position to remove the bottlenecks caused by the piling up of unfinished work? Hit me with your war stories by posting your comments below.