Curse of the icebox

Ice in fridge

I used to use Pivotal Tracker to manage my development tasks. I had tickets booked for the current integration, my backlog would include everything for the next few iterations and then there was the dreaded icebox.

As a solo developer I tracked everything in one “project” and used epics to separate all my projects. Every couple of weeks, I would go through my backlog and re-order my tasks. The priority of tasks changes over time, there are bugs, user feedback or simply new features you want to add. During these “reviews”, I’d occasionally come across a task that wasn’t as important as the rest. It should be completed at some point but not now or anytime soon. These tasks would get moved into the icebox.

Task priority

I have numerous active projects and deciding which tasks are the most important is difficult. I’ve always found it is easier to decide which tasks aren’t as important, this made the icebox easy to fill.

My backlog was always “full”. I’d work through everything for the iteration and then new work would come in. The churn was surprisingly good. I’d typically have 4-6 iterations of work lined up. The icebox though, it kept growing. There was this light blue list of tasks which kept growing. It just sat there getting bigger and bigger, staring at me, occasionally laughing.

Eventually, I’d had enough. I was looking at the icebox and saw lots of tickets, many years old. The tickets were still relevant, but they just weren’t as important as everything else, hence their consignment to the icebox.

Good-bye icebox

I went through the icebox and transferred anything interesting (most of it) to a text file labelled “future ideas”. I still have the list, but it no longer stares me in the face every single day.

As soon as I had disposed of the icebox, Pivotal Tracker didn’t make much sense. I had two lists, but it was really one list ordered by priority. I decided to ditch Pivotal Tracker and switch to the free tier of Pivotal Tracker is pretty feature rich, I no longer needed labels, epics, or anything else, I just wanted a simple list. At its simplest, is a list of tasks which can be grouped, it was perfect.

I only add a ticket to Monday if I think I will get to it within about two weeks. This is complicated with multiple projects as I might not work on a specific project for a couple of months, but the rule still applies. The “two weeks” is based on project time. If by the time I next work on this project, I expect to get to this task with two weeks, it goes on the list.

Everything else goes in the future ideas file. I review my future ideas file every now and again to see if there is anything I need to pull out or anything which can be deleted. I’ve found that often I delete entries from the future ideas text file as I’ve already done them. I’ve created and prioritised tasks because the idea was fresh in my mind, and I fit it in when I had space.

Simpler works

I’ve no idea why it works this way, but I’ve found that this simpler system makes me feel more productive. I really wish I’d switched sooner.

When I’m working on a freelance project for a client or in the preliminary stages of development for a new project, the process changes. The need to focus on one thing means I have less time for everything else. Whilst I focus on one project my inactive projects get more tickets and the “work” for each group grows. Once my time is freer, I try to get back to two weeks of planned work for each project.

Solo developer – multiple projects

A person sitting on a tiny island working on their laptop

I have numerous projects on the go and many more waiting to be started. There are not enough hours in the day to work on everything on my to-do list.

I’m good at finishing projects, it is rare that I start something and do not get it to a useable point (though it can happen). I tend to only start a project when I consider it worthwhile, have a real passion for it or think I will learn something significant from creating it.

The categories

To try and manage everything, I loosely group my projects into three groups. These groups are “have to work one,” “have to support” and “want to work on”. I have not been able to think of better names so we will stick with these for now. I use these categories to prioritise my limited development time. All my projects get some development time, but the categories help me decide how much each group gets.

“Have to work on”

My API is the backbone for all the Apps under the Costs to Expect umbrella. The API is the only constant (for now) in the “have to work on” group. The API is continuously reviewed, and I try to spend a reasonable amount of time refactoring and rewriting. Continuously refactoring the API has paid dividends, I rarely find significant issues or bugs. Any section of the API which feel a little “meh” get reworked. When I work on the API, I try to make sure each new release include more tests and I try to improve the documentation.

“Have to support”

“Have to work” on and “have to support” are subtly different. “Have to support” means bug fixes and upgrades. “Have to work on” means bug fixes, refactoring, new tests, and any necessary development. Many of my Apps live in this group, I fix issues as they arrive and try to keep them all running well.

“Want to work on”

My “want to work on” group changes constantly, this is the new and interesting stuff. I’m writing Budget Pro right now; it is a new App for the Costs to Expect service. I am hoping to release the alpha of Budget Pro before the end of June. As soon as a project in this group gets to a “releasable” state, it moves into one of the other two groups.

New stuff

When projects move between “categories” I find time for the new stuff. I might start something completely new; client work might come in or I decide to go back to one of my other projects.


You might think that over time it is inevitable that the “have to support” group grows too big for one developer to manage. If this happens, I will employ someone to work with me. I have gotten close to needing help a couple of time but so far, I’ve been lucky and always managed. Less active projects naturally get retired, either their times passes, or I’ve moved on.

I love having so many projects on which I can work. I can switch between backend and frontend at will, switch entirely to support or testing or just focus on something new, like C++.