Popular accounts of quantum computing emphasise more: more qubits, more gates, more ambitious algorithms. Inside the field, a surprising amount of practical progress comes from the opposite direction. Current quantum hardware is noisy and limited, so researchers and engineers spend much of their effort removing things from circuits, from experiments and from problem statements. This list collects eight things that quantum computing teams routinely take out in order to get better results, with the reasoning behind each. The theme throughout is that on today’s machines, every extra operation is a chance for error, so cutting before adding is not a slogan but a working discipline.
1. Redundant gates in a circuit
A quantum circuit is a sequence of operations on qubits, and every operation on real hardware has a nonzero chance of introducing error. Compilers therefore look for pairs of gates that cancel each other out, adjacent rotations that can be merged into one, and sequences that simplify to nothing. Removing them leaves the mathematical result unchanged while shortening the circuit.
The principle is easy to state: if two steps produce the same effect as zero steps, take both out. Circuit optimisation is, in large part, systematic subtraction.
2. Depth that the problem does not require
Circuit depth, the number of sequential layers of operations, matters because qubits lose their delicate state over time. A deeper circuit gives noise longer to accumulate. Engineers often restructure an algorithm so that operations that do not depend on each other run in parallel, flattening the circuit.
Well-known building blocks illustrate the trade-off. The quantum Fourier transform sits at the centre of several famous algorithms, and a clear description such as an explanation of the transform as the quiet engine inside many quantum methods shows how many operations it demands. Approximate versions that skip the smallest rotations are a standard example of deliberately dropping detail to reduce depth, accepting a tiny loss of precision for a more reliable run.
3. Qubits that add noise but not value
Not all qubits on a device are equal. Some have shorter coherence times, some suffer more from interference with neighbours, and some connect poorly to others. A common practical step is to map a program onto the best-behaved subset of the chip and leave the rest idle.
Using fewer qubits can therefore give a better answer than using more, simply because the weakest ones are excluded. The calibration data published by hardware providers exists largely to support this kind of selection.
4. Unnecessary entanglement
Entanglement is a source of quantum advantage, but it is also costly. Creating it requires two-qubit gates, which are typically noisier than single-qubit operations. If a part of an algorithm can be arranged so that fewer qubits need to interact, the circuit becomes less error-prone.
Researchers designing variational algorithms often test simpler arrangements of connections first and add structure only when the problem demands it. This keeps the experiment interpretable as well as hardware-friendly.
5. Parts of the problem a classical computer handles better
Another important subtraction happens before a quantum computer is involved at all. Many problems contain components that classical methods solve quickly. A sensible workflow strips these out, reduces the problem to its genuinely hard core and sends only that to the quantum device.
Optimisation tasks are a good illustration. A primer on the way quantum methods go after tough optimisation puzzles makes clear that these methods target specific structures, not everything. Pre-processing that removes obviously irrelevant variables or constraints shrinks the instance and makes any quantum step more tractable on small devices.
6. Noise, through mitigation and careful scheduling
Full error correction requires large numbers of physical qubits per protected logical qubit, which is beyond current devices at useful scale. In the meantime, error mitigation techniques try to subtract the effect of noise from results after the fact. Examples include estimating how results change as noise is deliberately amplified and extrapolating back to the zero-noise case, or discarding runs that fail a consistency check.
Scheduling choices also remove noise at the source. Placing operations to avoid idle time on sensitive qubits, and avoiding busy neighbours, reduces unwanted interactions. These measures do not eliminate error, but they lower it without adding hardware.
7. Measurements and shots you do not need
Quantum results are probabilistic, so experiments are repeated many times, and each repetition is called a shot. It is tempting to take a very large number of shots by default. But the number required depends on how precisely you need to estimate a quantity. Clever grouping of measurements, so that several quantities are read out simultaneously, can cut the number of runs considerably.
Dropping measurements that contribute negligibly to the final estimate is a routine efficiency step. It saves hardware time, which on shared cloud devices is a scarce resource.
8. Ambition in the first experiment
Finally, good researchers cut scope. A first experiment on a new device or algorithm is usually reduced to the smallest case that still tests the idea: a handful of qubits, a toy instance, a simple benchmark. If it works, the problem grows. If it does not, the failure is easy to diagnose because there is little to blame.
This habit is partly a matter of honesty. Claims about quantum advantage need careful baselines, and large, tangled experiments make baselines hard to establish. Small ones keep the logic visible.
A worked picture, without the maths
Imagine a small circuit written by a student for a toy problem. As first drafted, it contains a handful of gates that were added while experimenting and never removed: two operations that undo each other, a rotation applied twice in a row that could be a single rotation, and a connection between two qubits that ends up having no effect on the final measurement. A simulator confirms that deleting all three leaves the output distribution unchanged. On real hardware, the shorter version typically gives cleaner counts, because each deleted operation was one more chance for noise.
This is why many tutorials now teach optimisation passes early. Learning to read a circuit diagram and ask “what is this doing for me?” is as useful as learning to build one.
What these eight have in common
Every item above responds to the same underlying fact: current quantum devices are fragile. That makes subtraction an efficient route to improvement. It is also a reminder for newcomers that headlines about qubit counts tell only part of the story. Quality, connectivity and the length of a circuit matter at least as much as raw numbers.
It would be misleading to suggest that removal alone solves the field’s challenges. Scaling to fault-tolerant machines will ultimately require adding a great deal: more qubits, better materials, new architectures. The point is narrower and practical. With the hardware available today, the cheapest improvement is usually the one that takes something out.
A note for those learning the field
If you are studying quantum computing, try applying the same attitude to your own notes and projects. After running a circuit in a simulator, ask which gates you can remove without changing the output. Jot down which edits changed nothing and which ones quietly broke the answer. Putting those observations into words helps them stick. A site like BlogOrbix, which bills itself as a distraction-free corner of the web for writers, offers a Google sign-in and a Latest page where such short lab notes can sit alongside other people’s writing.
Quick reference list
- Cancel and merge redundant gates.
- Trim circuit depth to what the problem needs.
- Leave weak qubits idle.
- Avoid entanglement you cannot justify.
- Hand classical-friendly parts to classical methods.
- Subtract noise through mitigation and smarter scheduling.
- Skip measurements and shots that add little.
- Shrink the first experiment before scaling it.
None of these steps is glamorous, and none will make a headline. Together they explain why experienced practitioners are often more excited by a shorter circuit than by a larger one. As the hardware matures, the balance will shift. Until then, the habit of removing first remains one of the most reliable tools the field has.
