Can Computing Wait for a Better Moment?

Software tends to treat time as a performance problem. Faster is better, queues should empty and jobs should begin as soon as resources are available. For interactive services, speed can be essential. Nobody wants an emergency system to wait for cheaper electricity.

But much of computing is not an emergency.

A publication generates several image sizes after an upload. A team builds search indexes overnight. Backups, analytical reports and model training have deadlines rather than immediate users. Their start times may be flexible by minutes or hours. Meanwhile, electricity grids change as demand rises and falls and different sources become available.

What if software could wait for a better moment?

Carbon-aware computing uses information about electricity to influence when or where flexible work runs. The concept ranges from simple schedules to complex systems that shift workloads between regions. It is easy to turn this into a grand claim about clean software. A more useful starting point is a small experiment whose limitations remain visible.

Consider the image pipeline for an independent publishing site. Original photographs should become available quickly enough for editing, but archival renditions and less common sizes might not need immediate processing. A queue could assign each task a deadline. When local grid intensity is lower within that window, the worker runs. If no better period appears, it completes before the deadline.

The prototype would need more than an emissions data feed. It would record how long jobs wait, whether editors notice, how many tasks miss their preferred window and how much computation is actually involved. If the total workload is tiny, the scheduler’s complexity and hosting may outweigh the benefit. That is a valid result.

Reliability is another constraint. External carbon-intensity data may be delayed or uncertain. The system needs a safe fallback rather than allowing work to accumulate indefinitely. A simple time-of-day schedule based on the regional grid could be more robust than real-time optimisation. Precision should earn its operational cost.

Location shifting creates harder questions. Moving a workload to a region with a cleaner grid can increase network transfer, duplicate storage or place data under different legal conditions. Water stress may differ even when electricity looks favourable. The greenest number in one dataset does not represent the whole consequence.

There is a human dimension too. Flexible computing should not become flexible labour by accident. If reports complete at unpredictable times, someone may need to adjust their day. If a low-carbon window coincides with peak demand for users on another continent, system performance may worsen unevenly. The people relying on the work define which deadlines are genuinely flexible.

This is what makes the experiment interesting. It expands scheduling from a purely technical concern into a negotiation between usefulness, resources and time. A job specification could state not only CPU and memory but urgency: interactive, deadline-bound or deferrable. Product teams would have to decide which category is truthful.

Those decisions can reveal avoidable habits. A dashboard regenerated every five minutes may be viewed twice a day. A development environment may run overnight because nobody configured it to stop. A model may be retrained on a calendar even when the underlying data barely changed. Before shifting computation, the best intervention may be removing work that serves no purpose.

The interface could make waiting visible without becoming intrusive. An administrator might see that a non-urgent job is queued for a lower-impact window, its latest completion time and an option to run it now. Transparency turns the scheduler from mysterious automation into a choice people can understand and occasionally override for a real need.

Carbon-aware scheduling will not make a wasteful product sustainable. It addresses one part of energy use, and estimates remain imperfect. Its greater value may be conceptual. Software has trained us to experience computation as immediate and locationless. Designing for flexible time makes infrastructure visible again.

The first prototype can be modest: one queue, one region, one class of non-urgent jobs and a public record of what happens. Perhaps waiting saves little. Perhaps it reveals a meaningful pattern. Either way, the experiment asks a question that ordinary performance metrics omit: not only whether the computer can work now, but whether now is the responsible moment to ask.