Plans that survive reality

In the previous post, I wrote about a basic problem with task managers: although they remember tasks for you, they still expect you to do most of the actual management. You must decide when each task should happen, keep the plan up to date, and repeatedly choose what to do next. These are precisely the kinds of decisions which become difficult during periods of executive dysfunction.

Subroutine is built around reducing that planning work. Two of its most important features are the Timeline, which deals with when actions happen, and the Queue, which deals with what should happen next. Before explaining either one, however, it is useful to look at the problems they are intended to solve.

The trouble with time blocking

A todo list can tell you what needs to be done, but it says very little about whether all of it can actually fit into a day. Time blocking tries to solve this by assigning a period of time to each task. Instead of writing “clean the kitchen” and hoping to get around to it, you might reserve thirty minutes for it at 6:00 PM. This makes the cost of a task visible and forces the plan to account for the fact that time is limited.

For many people, including myself, this can work much better than a list of vague deadlines. A task scheduled at a specific time is easier to understand than one which is merely marked “high priority.” It also becomes possible to see when a day is overloaded before you are already in the middle of it.

The problem is that time blocking creates another schedule which must be maintained. Tasks rarely take exactly as long as expected. Meetings run late, travel takes longer than planned, energy changes throughout the day, and unexpected responsibilities appear. If one block moves, everything after it may need to move as well. After enough changes, repairing the schedule can take almost as much effort as following it.

Calendars do not handle this especially well because they generally treat everything as a fixed commitment. A dentist appointment really does need to remain at 2:00 PM, but “fold laundry” probably does not. Putting both on a calendar makes them look equally rigid, while leaving tasks in a separate todo list hides the relationship between the time you have and the work you intend to do. Either way, you are responsible for repeatedly fitting the pieces together.

The Timeline

Subroutine's Timeline puts actions and events on the same continuous view of time without pretending that they are the same thing. Events are fixed commitments which other work must fit around. Actions can have a duration and a scheduled time, but they can remain flexible unless you explicitly pin them in place. This distinction gives the scheduler room to help without taking control away from you.

If an action must happen at a particular time, you can place it directly on the Timeline and pin it there. If it only needs to happen sometime after other queued work, Subroutine can find the next available slot around events and pinned actions. You can still drag and resize items yourself, but you do not need to manually place every ordinary action in order for it to appear in the plan.

The difference becomes more important when the plan goes wrong. Subroutine can refresh the Queue and move overdue, flexible actions forward while preserving fixed commitments. Rather than presenting yesterday's unfinished work as a growing collection of red due dates, it can turn that work back into a schedule which is possible from the present moment. Rescheduling is currently an explicit action rather than something which happens continuously in the background, but the underlying idea is that a missed block should be recoverable instead of invalidating the rest of the plan.

Subroutine also supports creating a Batch of actions for times when you already know what you want to do. A batch means “I am doing these actions, in this order, starting now.” The actions are placed back-to-back, fixed commitments are respected, and flexible work already in the way can be pushed later. This is a small distinction, but an important one: sometimes you want the scheduler to choose the next available time, and sometimes you have already made the decision and simply need the schedule to catch up.

The Timeline is not intended to create a perfect plan which must be obeyed. It is a representation of what currently seems realistic. When reality changes, the representation should be allowed to change with it.

Lists do not know what comes next

Even a perfectly maintained schedule does not completely answer the question of what to do next. Traditional task managers usually approximate this with priorities, sections, tags, or manually ordered lists. These are useful organizational tools, but they tend to describe tasks in isolation.

In practice, whether an action makes sense depends on the state of everything around it. You may have twenty minutes before an appointment, but the highest-priority task takes an hour. You may need to buy groceries, but not until you have finished making the list. A phone call may require another person to be awake, while an errand only makes sense once you have already left the house. Two tasks with the same priority can therefore be completely different choices in the current moment.

Dependencies make this even more complicated. Some actions cannot begin until another action is complete; others become much easier when grouped by location, tools, or mental context. Every time one of these conditions changes, the useful order of the list changes too. A static priority number cannot express all of that, so the user ends up scanning the list and reconstructing the relevant context in their head.

Once again, the task manager stores the information while leaving the management to you.

The Queue

In Subroutine, the Backlog contains actions you may intend to do, while the Queue represents actions you have committed to doing. Queueing an action gives it real space in the schedule. The current scheduler considers its duration, the work which is already queued, and fixed events or pinned actions before choosing its next available slot. The result is a chronological agenda rather than another manually sorted priority list.

This also gives Subroutine a concrete definition of “next.” At the moment, the next action is primarily the earliest action in the Queue. The Focus view can surface that action, keep it in front of you, and advance after it is completed. This is deliberately simpler than claiming that the app can somehow know the perfect thing to do. Subroutine currently computes a schedule from explicit constraints; it does not read your mind or learn your behavior.

The longer-term goal is for the Queue to make a better prediction by understanding more of those constraints. Dependencies could prevent an action from appearing before its prerequisites are complete. Context could make actions eligible only when the necessary time, place, tools, people, or capacity are available. When one condition changes, flexible actions could be reorganized while fixed commitments remain where they belong.

“Prediction” in this sense does not mean an opaque algorithm deciding how you should live. It means reducing a large backlog to a small set of actions which are actually possible and sensible right now. The reasons should remain understandable, and the user should always be able to override the result. The purpose of the Queue is to carry routine ordering decisions, not to replace personal judgment.

Two views of the same plan

The Timeline and Queue approach the same plan from different directions. The Timeline answers When will this fit? The Queue answers What comes next? An action moved in one view is not copied into a separate system; both views reflect the same underlying schedule.

Together, they are intended to make planning less fragile. The Timeline creates room for work without confusing flexible actions with fixed appointments. The Queue turns that schedule into a manageable next step instead of asking you to repeatedly reconsider everything in the backlog. Neither feature eliminates uncertainty, interruptions, or executive dysfunction, but they can reduce the amount of manual repair and decision-making those things normally create.

Subroutine is still in active development, and the more context-aware parts of the Queue in particular are not finished. Future posts will cover dependencies, context and scheduling behavior in more detail as those systems develop. The goal remains the same: a useful plan should not only organize an ideal day; it should continue helping after the ideal day changes.