When you have to go downhill first
2026-08-15 · Adaptation & Evolution
"Every step better than the last" sounds like the safest way to work. For a whole class of problems it is the one rule that guarantees you never reach the best position — not because you stopped too early, but because you followed it correctly.
You have probably lived through this. You try to move in a new direction, and for the first six months nothing goes well; you are visibly worse than you were. So you go back. Or there is a tool you have used for years, you know a better one exists, but switching means relearning and a real dip in output — so every year you decide to switch next year.
The usual explanation is willpower, or sunk cost. Both are real, but they turn a structural fact into a psychological one. The colder version: in many systems, getting from a good position to a better one necessarily passes through somewhere worse. That is not bad luck; it is the shape of the problem. And the rule that sounds beyond reproach — never accept a step that makes things worse — is precisely the nail pinning you in place.
The previous topic was about putting agents into a computer and letting them run. This one looks at the same picture from the other side: what kind of terrain are those agents searching? The shape of that terrain — how many peaks, how deep the valleys between them — decides whether "keep improving" works at all. It is the base map for the next few topics on evolutionary games and coevolution.
In 1932 the geneticist Sewall Wright wanted to explain why species do not simply march in a straight line toward the optimum. He drew a picture that has since spread into every field: lay every possible combination of genes out on a plane, and make the height of each point its reproductive success. That is a terrain. He called it a fitness landscape, and the height is fitness.
The power of the picture is not the mountain metaphor. It is that the picture forces you to make three vague things explicit.
First, what counts as a position. A position is a whole configuration: a full genome in biology, a full set of design choices in a product, the current architecture of a codebase. Second, what counts as a neighbour. This is the one people skip, and it matters most — it fixes how far a single step can reach. In biology it is usually "change one base"; in an organisation it might be "change one process". Third, what height means. Some quantity you can actually compare: reproductive success, profit, tests passed.
Once those three are fixed, one move acquires a precise name: stand where you are, look at every neighbour, move to any that is higher, stop when none is. That is hill climbing. Strip almost any "continuous improvement" practice down and this is what is left.
Three switches are already enough for the damaging thing to appear. Starting from 000 and always climbing, you land squarely on 011 (height .71), while the highest point on the board is 110 (.83). You made no mistake; every step was the best available at the time. What keeps you out is not error. It is the rule that no step may make things worse.
That 011 has a formal name: a local optimum — a position no neighbour beats. The genuinely highest point on the whole terrain is the global optimum. A landscape can hold very many local optima and exactly one global one.
The property to keep your eye on is this: standing on a local optimum, local information cannot tell you whether you are on the global one. The two feel identical — look around, everything slopes down. To learn the difference you must either see far away, or walk down and find out.
So "getting from here to somewhere better" acquires a quantifiable cost, and it is two numbers: how deep the valley is (how far below today's level the worst point sits) and how long the valley lasts (how long you spend below today's level). Neither number has anything to do with how good the destination is. A clearly superior option can sit behind a deep, long valley; a marginally better one may be a single step away.
Split those two numbers apart and a lot of "failed reform" stories read differently. Most reforms do not die on the plan; they die because the mandate is shorter than the valley. And from the outside the valley is a perfectly real decline, so the conclusion "this direction isn't working" is fully supported by the data.
Before starting anything that swaps one way of working for another, write down two numbers: valley depth (how far below today you will fall, on a metric you already track) and valley duration (how long until you are back to today's level). Then ask: can you get a mandate for those two numbers? If not, do not start — build in parallel instead: stand up a second track without dismantling the existing one, and switch only once it has climbed above today's level on its own. The commonest cause of death in the valley is not a wrong plan; it is being cancelled mid-valley by your own monthly metrics.
The next question follows by itself: why do some terrains have a single summit — in which case hill climbing is all you need — while others bristle with peaks? What sets the ruggedness of a landscape?
In 1987 Stuart Kauffman and Simon Levin gave a startlingly clean answer → ref · the Santa Fe school. They built a toy model with exactly two knobs, the NK model → ref · NK fitness landscape:
N is how many components the system has (say 20 switches). K is how many other components each component's own contribution depends on. That is all. K is simply the degree of interdependence.
The results are remarkably tidy. At K = 0 every component minds its own business, so you can tune them one at a time without disturbing anything else — the landscape has a single peak and any climbing path reaches it. As K grows, changing one component scrambles the contributions of more and more others, and peaks multiply, sharpen and separate. At maximum K, where every component depends on all the others, the landscape becomes fully random and the number of local optima is 2ᴺ⁄(N+1) — for N = 20, roughly fifty thousand.
The weight of this is that ruggedness is not fate; it is a consequence of your architecture. "Around here everything breaks when you touch it, incremental improvement just doesn't work" is usually heard as a complaint about capability or morale. More often it is a measurable structural parameter talking. And structural parameters can be changed: break dependencies, define interfaces, separate components that are tangled together. None of those moves improves any metric directly — what they do is flatten the terrain so that small improvements start working again. This is the other face of near-decomposability from Topic 3: modular systems survive because they build themselves a less rugged landscape.
When small steps stop paying, do not add people or time first — measure K. Concretely: list the components of the thing you want to change and, for each, ask how many other components a change to it would disturb; take the average. Once the average is past two or three, any point improvement will be cancelled out by degradation elsewhere, and the link between effort and result visibly weakens. What to do then is decouple — define interfaces, cut dependencies, kill cross-module implicit assumptions — not optimise. Decoupling raises no metric of its own. What it raises is the yield of every future optimisation.
If pure climbing gets stuck, you have to allow the occasional step downhill. But if you always step downhill you are merely wandering and never settle anywhere. The dilemma has a name: exploration versus exploitation — go look elsewhere, or dig deeper where you stand.
The most elegant resolution came in 1983 from three IBM researchers (Kirkpatrick, Gelatt and Vecchi): simulated annealing. Accepting a worse position is given a probability, controlled by a parameter called temperature. Hot, and you are quite happy to move downhill, so you roam the whole terrain; cold, and you accept almost nothing but uphill moves. Then you lower the temperature slowly over time.
The name comes from metallurgy: cooled slowly, atoms have time to settle into a low-energy ordered structure; quenched, they freeze wherever they happen to be. The crucial object is not the permission to get worse — it is the cooling schedule: when, and how fast, that permission is withdrawn.
The same idea grows different shapes elsewhere. → ref · genetic algorithms use no temperature; they use recombination: take half of one decent configuration and half of another and stitch them, landing far away in a single move — effectively swapping in a different definition of "neighbour", so that two peaks separated by a deep valley may now be one step apart. The multi-armed bandit problem strips the dilemma to its purest form: several slot machines, unknown payouts, and every pull is a choice between trying the one you have barely tested and pulling the current best. One result recurs across the mathematics: the optimal share of exploration rises with how many rounds you have left. So the same person on the same problem should explore at different rates in January and in November — not a matter of mood, but something you can compute.
Write exploration as a budget and a cooling schedule, never as an attitude. Three concrete things: ① fix a share (say 20% of time or money) for directions uncorrelated with what you already do; ② give that share its own evaluation standard — judge it by how many directions it ruled out, not by its return, because the output of exploration is information rather than return; ③ write the cooling schedule in advance: the date after which no new directions open and resources come back. Without ③, "staying open" runs hot forever and never converges. Without ②, the exploration budget is absorbed by the main line's metrics inside one quarter.
The fitness landscape is the handiest picture in complexity science and the easiest to misuse. The problem is not that it is wrong; it is that the little three-dimensional hill is so pleasant to look at that you forget what it left out.
First, the dimensions are a lie. A terrain drawn on paper has two lateral degrees of freedom, so each point has a handful of neighbours and peaks must be separated by valleys. Real configuration spaces are not like that: twenty switches give twenty directions of neighbour and a million positions. In high dimensions, being completely surrounded by lower ground becomes rare — there is usually a near-level ridge around. The evolutionary biologist Sergey Gavrilets calls this a holey landscape: in high dimensions the high-fitness regions join into one connected web, and lineages can diverge without ever going downhill. That directly weakens Wright's classic argument that small populations and random drift are needed to cross valleys.
Second, the terrain is not dead. An NK landscape fixes every height before the run starts. In reality others are moving too: the peak you climbed can sink because a competitor, a regulator or a change in taste sank it, and can rise because someone else opened a route to it. That is coevolution, the subject of Topic 31. Once the terrain moves, "reaching the optimum" stops being the goal and speed of movement — plus distance to the nearest ridge — takes its place. It is also why "we are already the best in the industry" carries no information about next year.
Third, height may not exist. A landscape assumes one scalar you can compare. Real "good" is usually several incommensurable things: fast and stable, growth and margin, coverage and precision. Multi-objective problems have no highest point at all, only a whole set of solutions none of which beats another on everything (the Pareto front). Compressing them into one "overall score" does not solve the problem; it hides the choice of weights inside a formula.
Fourth, the picture was contested from the start. The historian of science William Provine argued in 1986 that Wright's landscape diagrams silently mixed two incompatible coordinate systems — the space of genotypes and the space of gene frequencies — and do not stand up as mathematical objects. That does not stop them being useful for thinking, but it does flag something: this is a visualisation of a metaphor, not a model you can put numbers into. Whenever you hear "we're at a local optimum in our fitness landscape", ask first: how is your neighbourhood defined, and which quantity is the height? Without answers, the sentence is just an expensive way of saying "we're stuck".
One more thing worth separating out: ruggedness is not a property of the terrain alone either. It is a joint property of terrain and move set. The same set of configurations may be brutally rugged if you can only flip one bit at a time, and lose half its peaks if you are allowed to swap two whole modules. So being stuck leaves a third option besides trying harder and descending: change the move set.
Before diagnosing yourself as being at a local optimum, fill in three blanks: neighbourhood (what one step can change), height (which specific metric), and whether the terrain moves (how often you re-estimate it). With all three filled, "go downhill first" is an executable judgement; without them, drop the vocabulary — at that point it explains nothing and merely supplies a handsome picture for "we're stuck". And when stuck, try in this order: first see whether the neighbourhood can change (different tools, different collaboration, cross-domain recombination), then consider crossing the valley. Changing the neighbourhood is usually far cheaper.
No, but it applies more narrowly than usually assumed. What matters is how rich your neighbourhood is: biological evolution has thousands of mutable sites, so detours abound; an organisation can typically change two or three things at once, so its effective dimensionality is low and the valley is a real valley. The test is therefore not "is this system complex" but "how many things can I change in one step". It also explains why the same transition is a gentle slope when you can move people, process and incentives together, and a cliff when you can only move one.
There is no universal optimum — the bandit-optimal exploration rate depends on rounds remaining, the variance of payoffs, and switching costs, all of which differ by situation. The value of a fixed share is not that it is optimal but that it converts something that gets eaten by short-term pressure into a default. The part worth arguing over is not the percentage but whether there is a separate evaluation standard and an explicit cooling date; without those two, any percentage goes to zero in the first tense quarter.
This topic's mechanisms cannot help, and that is the honest part: a landscape's shape is only clear afterwards. What you can do is fix the criteria beforehand — at launch, write down the expected valley depth and duration plus a falsifying condition (if by time X sign Y has not appeared, withdraw). The difference is not whether you can foresee, but whether the withdrawal rule was set before the valley or during it. Set during it, any rule gets rewritten by how much it currently hurts.
It does, and a real one. Lowering K means giving up synergy between components — a highly tailored, tightly coupled design often sits on a higher peak than a modular one. So this is an explicit trade: peak height for terrain smoothness. When the environment is stable and the goal fixed, coupling pays; when the terrain itself moves and you must re-aim often, smoothness is what is worth money. Treating decoupling as a universally correct principle means dismantling your building blocks precisely when you should be digging in.
It means there is a commonly overlooked third option when stuck. Besides trying harder (same move set) and crossing the valley (paying the cost), you can change the neighbourhood: different tools, different collaboration, or some way of altering several components at once — recombination in a genetic algorithm, or handing a problem to an entirely different team in an organisation. Changing the neighbourhood usually costs far less than crossing a valley, but it requires noticing that "what one step can change" is designable rather than given.