Two weeks, two stacks, one flat battery: Run A so far

The sinews post described an experiment that had just started: whether an architecture that keeps data off the control flow keeps an AI agent from piling complexity into a few places. Its first run has now been going for a little over two weeks. This is a progress report, not a results post. It says how far the run has got, what went wrong along the way, and when it should finish. It deliberately says nothing about how either stack is doing.

The results of this experiment are meant to be read once, over complete runs, with the tests registered before the data. Looking at trajectories halfway through is how an experimenter starts nudging an experiment, even without meaning to. So this post only uses what the run's operation shows: which checkpoint each chain has reached, the logs of the waits and the restarts, and how long the queue of tests is. The correctness, cost and structure of the code are left alone until the end.

What is running

This is Run A of three: the two stacks as they were built, side by side. A later run crosses the front ends and back ends, and a third adds a control stack with no injection of any kind.

what	Run A
stacks	Angular on Spring (dependency injection, halfway) and TanStack on OfficeFloor (function injection, additive)
change requests	250 per chain, in five acts of fifty, every fourth one changing behaviour that already exists
chains	10 per stack, one after another, each starting from the same almost empty application
agent	Claude Opus 5.5, a fresh session for every request, shown only that request's own test
condition	just-solve: the bare change request, with no structural guidance or grading
tests	each request's own test after every checkpoint; the full suite of every test so far after every tenth checkpoint and the last
size of the job	2,500 agent checkpoints and 2,510 test jobs per stack
started	27 October 2026, just after midnight Perth time, both stacks within a second of each other

The plan was for two laptops, one per stack. In practice both stacks, each with its own test processor, run on one laptop. Each run has its own working directory, test queue and ports, so they do not interfere with each other. They do compete for the same CPU, and that matters for how long the testing takes, as described below.

Before it started: the stream's own bugs

Every expected value in every test comes from a reference model of the application, and three generated two-user scenarios sit beside each request's story. A thousand tests by the end means a thousand chances for the model, the test generator or a test helper to be wrong. So before Run A, the stream was calibrated on both stacks twice.

The rule for telling the stream's bugs from the agent's was simple. Two different agents building two different stacks will not make the same mistake at the same step of the same scenario. If both stacks fail a test in the same way, the stream is wrong.

• First calibration (one chain per stack). From checkpoint 86 both stacks failed the same generated scenarios at the same steps. The causes were in the model: a date worked out in calendar days instead of business days, and identities kept as positions, which were reused after a merge or a transfer. Twenty-two requests were also reworded to say rules the model had been applying without stating them.
• Second calibration (two chains per stack). About seventy tests failed in common or across chains. Each one was replayed through the model and read against its request. About fifty-five turned out to be the stream's, from eighteen causes, and each was fixed where it lived.

No rule was weakened to make a test pass. The second set of fixes was committed on 26 October, the night before Run A started, and nothing has been committed to the harness or the stream since. A fault found during a run is fixed after the run, for the next one. A running stream does not change.

Where it has got to

As of the evening of 12 November:

	Angular / Spring	TanStack / OfficeFloor
chains finished by the agent	7 of 10	6 of 10
agent working on	chain 8, request 14	chain 7, request 114
checkpoints committed	1,763 of 2,500 (71%)	1,613 of 2,500 (65%)
tests running on	chain 6, full suite at request 240	chain 6, request 85
test jobs done	1,494 of 2,510 (60%), 276 waiting	1,339 of 2,510 (53%), 279 waiting

Every agent session so far has finished. None of the 3,376 has ended in failure, and none had to be cut short and gated on its partial work. No test job has errored either. A test job that fails some of its tests is still a job that ran, and those numbers are what this post leaves out.

The gap between the two stacks should not be read as a result. Wall-clock time on a shared laptop mixes the agent's own work with whatever else the machine was doing. The agents' cost, turns and time will be compared properly, over complete chains, at the end.

What happened along the way

The run is designed not to stop for anything a person can fix later. If the usage limit is hit, a token is rejected, the API fails or the network drops, the agent turn waits and tries again, indefinitely. The test queue is on disk, so a test job that dies is simply run again. Both of those were tested for real.

when (Perth time)	what happened	effect
27 Oct 00:03	Both stacks start chain 1.
27 Oct 10:24 to 29 Oct afternoon	Usage limit reached. Both stacks share one account, so both waited, retrying every half hour (107 times each).	About 53 hours of waiting. That is why chain 1 took about 80 hours on both stacks, against 26 to 37 hours for every chain since.
4 Nov 01:58	Weekly usage limit reached.	Both agents waited again, 49 retries each. The test processors kept working through the backlog.
5 Nov 02:26	The laptop's battery ran out.	Everything stopped. Both agents were idle, waiting on the limit, so no agent work was cut off. Both test processors were partway through a full suite.
10 Nov 13:38	Both runs resumed with the same run ids.	Each chain continued from its last committed checkpoint. Each test processor found the job its predecessor had died in and ran it again from the beginning. Nothing was lost, apart from five and a half days.
10 Nov onward	Running without a stop since the resume.	The weekly limit had reset, so neither agent has had to wait again.

The resume was one command per stack, naming the same run and repository as before. It refuses a different repository, so a resumed run cannot quietly continue on the wrong stack. Its first lines in the log are a check worth showing. For every chain already finished it reports that checkpoints 1 to 250 are committed and leaves the branch alone. For the chain that was cut off, it names the checkpoint it is continuing from.

Smaller things the logs show, none of which needed anyone to step in:

• One agent process crashed: its JavaScript runtime died with a segmentation fault partway through a turn. The harness treated it as a transient error, waited a minute, and ran the turn again.
• One of the probes the harness runs to record what the agent touched timed out after fifteen minutes and was skipped. The checkpoint itself was not affected.
• One agent found its usual port still in use by an earlier application, started its own test run on another port, and carried on.
• One agent tried to write a log to /tmp, which its sandbox does not allow, and wrote it into its own task directory instead. The sandbox exists so the agent can never see a future test, and it held.

The long pole is testing, not the agent

The tests run beside the agent, not in its way. After every checkpoint the agent's commit is queued for testing and the next request starts straight away. A separate processor works through the queue in order, on a port of its own, with each job's tests fixed at the version of the harness it was queued under.

The plan budgeted about 45 minutes for the full suite at request 250, which is about a thousand tests. With two agents and two test processors sharing one laptop, it is closer to three hours. Full suites run every tenth request and grow with the application, so they take most of a chain's testing time. A whole chain has kept its test processor busy for 34 to 44 hours, while the agent finishes a chain in 26 to 37. So every chain the agent finishes adds to the backlog, which has grown since the resume to about 275 jobs per stack.

This affects only when the results arrive, not what they are. A chain's results are committed to its branch once its last test has run, and the order in which tests run cannot change their outcome.

When it should finish

These estimates use the rates of the chains finished since the first usage-limit stall, and assume no further stops:

	agent finishes	last test finishes
Angular / Spring	about Monday 16 November	about Wednesday 18 November
TanStack / OfficeFloor	about Tuesday 17 November	about Friday 20 November

Another usage-limit stall would push the agent dates back but barely move the test dates, because the test processors keep working while the agents wait. Another flat battery would push both back. Then the analysis runs over every checkpoint of every chain, and that will be the next post with numbers in it.

What this post leaves out, on purpose

Nothing here says whether either stack is passing its tests, what the agent is spending, or what is happening to the structure of the code. The runs record all of it at every checkpoint: the agent's whole session and diff, its cost and turns, every test's result, and every structure measure. All of it will be read together once both runs are complete, and compared chain against chain, ten a side. A run that is two-thirds done could be read as an early answer, and that is the reason not to read it yet.

What extraction cannot slim: the result, and what it means for your long methods

I registered a study before looking at the data: of the long methods that Extract Method can't fix, how many can function injection take apart? I said at least a quarter. The answer is a bit over one in five. I was wrong, and this post is about what the 580 repositories showed instead, because what they showed turned out to be more useful than being right: a way to classify the methods no split reaches, and from that three studies to refine the tools down to the few methods that are a real concern, then to check whether the same measures hold on AI-written code. The full paper, with every number generated by script, is What extraction cannot slim, and whether function injection can.

The short version

• Between a fifth and a quarter of long methods can't be fixed by Extract Method. Across 3 million methods in 580 Java projects, 5.6% of methods are long (26 code lines or more), and 22.8% of the long methods are stuck: no set of extractions gets the method under the cap without a return escaping a piece, a piece needing to hand back two values, or a piece needing more than five parameters.
• Function injection takes apart a bit over one stuck method in five, not one in four. 22.2% of the stuck methods, interval 20.3% to 24.3%, so my hypothesis is refuted. Function injection is not a general fix for stuck methods.
• Nearly half of the stuck methods are stuck only because of early returns. Guard clauses, a return inside an if. Extract Method can't take a piece that returns. A flow can, and the flow took apart three in four of those methods without inverting a single guard.
• Where Extract Method works, a sequence of functions is a little cheaper about a third of the time, and only a little. The methods where functions win are pipelines: stages in order, each stage using what the stage before produced. The saving is one or two values per method. That saving is not a reason to adopt a framework. That saving is a reason to write the pipeline as functions if you're already in one.
• The quarter of stuck methods that nothing splits is mostly not logic. A third of that quarter is tables and literals: giant switches of short cases, array initialisers, builder chains, argument lists. Most of the rest of that quarter is dense code where a jump lives inside a loop or a try, or where every cut would need too many values; a smaller part is a nested block too big to cut, such as an else-if chain or a try inside a try.

What was measured

580 open-source Java repositories, drawn at random by a separate tool with a seed fixed in advance, each repository pinned to the last commit before December 2020 so that none of the code was written with an AI assistant. OfficeFloorSlim, built on SinewSlim, scanned every production .java file and reported, for each long method, three things:

• whether SinewSlim can slim the method by extraction alone, pricing each cut by what crosses the cut (how that pricing works);
• whether the method comes apart as injected functions, where a return ends a function and a function can hand on several values;
• the split a developer would actually make, called the combined split: functions where the flow divides, extracted methods inside the functions, priced by the sum of both.

The costs were fixed in those tools before the sample was drawn. The study computes no cost of its own, because I wrote the tools and the framework, and a cost I could tune would be worth nothing.

	Count	Share
Methods with a body	3,026,902
Long (26 code lines or more)	168,466	5.6% of methods
Extract Method slims the method	130,033	77.2% of long
Stuck	38,433	22.8% of long

Those shares were the same whether a project had 200 stars or 50,000.

What the stuck methods are

Each stuck method was put in one bucket, testing the conventional fix first, so that function injection gets credit only for the methods nothing simpler fixes:

The stuck method…	Count	Of stuck
would slim by extraction if the method's early returns didn't exist	17,123	44.6%
slims by extraction if a record carries two values back	3,727	9.7%
only function injection takes the method apart	8,524	22.2%
nothing splits the method	9,059	23.6%

The 22.2% is the registered answer, and 22.2% is under the quarter I set. But look at the first row. "Would slim if the early returns didn't exist" is not a refactoring you can apply. To get rid of the early returns you invert the guards, thread a flag through nested ifs, or extract a piece that returns a flag the caller tests. Most developers would call the first two a worse design than the long method. The combined split handles the return as the return stands, and the combined split took apart 76% of those early-return methods without restructuring them. Of the stuck methods the conventional fixes can't reach at all, the combined split takes apart about half. That is the clearest thing in the data: single-exit extraction can't deal with an early return, and a flow can.

Where Extract Method already works

130,033 long methods can be slimmed by Extract Method alone. For each of those, the combined split was free to choose: keep the method as a method and extract pieces from the method, or cut the method into injected functions with extracted pieces inside the functions. The combined split chose functions, and the functions cost less than extraction, for 29% of those methods. Measured against plain extraction with no framework wrapper at all, the functions cost less for 17%. The median saving was 2. So the gain from functions is real, small, and specific to one shape of method.

The shape is a pipeline: 96% of the methods where functions cost less are straight sequences, stage after stage with no branching, each stage using what the stage before produced. Here is why a pipeline is cheaper as functions and other shapes are not. Extract Method prices a value twice when the value crosses a cut: once on the way out of the piece that produced the value, as a return, and once on the way into the piece that reads the value, as a parameter. Extract Method also prices the method's own parameters into every extracted piece that reads them. A flow between functions prices a value once, in the function that declares the value as a parameter, and a flow never prices the method's own parameters, because the framework injects them into whichever function needs them. The consequence: a boundary that one computed value crosses costs the same under both. Where two or three values cross one boundary together, or where a method parameter such as options is read in every stage, the flow is cheaper than the extraction. Where a boundary carries nothing at all, the flow still costs 1 and the extraction costs 0, so the extraction is cheaper. That is the whole mechanism, and the paper works two short examples through the formulas term by term.

The stuck methods that only injection takes apart have the opposite shape: 64% of those methods branch, an if or switch whose arms each do real work, usually with an exit inside an arm. A branch with an exit inside is exactly where a single-exit extracted piece fails, and exactly where a decision function with a flow per arm does not.

The quarter that nothing splits

9,059 stuck methods have no plan from either side. After the registered results were in, I re-read all 9,059 methods from source to see what the methods are. This re-reading wasn't registered; the re-reading is there to decide what the tools should do with the methods they stop at, which is the programme at the end of this post.

• A third of the 9,059 are tables and literals (3,030 methods): switches of short cases, flat lookup switches, array initialisers, long argument lists, builder chains, string concatenations, constructors that only call super(…). The cognitive complexity of these methods is about zero. These methods are long because they hold data or options, not logic. If your linter flags one of these methods, the linter is flagging a table, and arguably the linter shouldn't.
• Most of the rest of the 9,059 is dense. In 91% of the methods blocked by a jump, the jump is inside a loop, a try or a switch, and a step that breaks out of the loop enclosing that step can't become a function. Where an if blocks the split, the obstacle is the values the branches pass on, not the branching. And raising the five-value limit helps less than you'd think: a limit of six rescues 4.4% of the 9,059, a limit of ten rescues 12.5%, and a third of the data-coupled methods have no plan even at ten.
• Shape, not complexity, keeps a method on this list. At the same length, the 9,059 methods are no more complex than the methods injection rescues.
• The list clusters. 32 projects hold 40% of the 9,059 from 22% of the long methods. The tables cluster hardest, which looks like generated code or a house style of building data in code. The dense logic is spread evenly across projects, which looks like how people write.

What this means for the method you're looking at

The method looks like	What 580 projects say
Stages in order, each stage using what the last stage produced, no early exits	Extract Method works. Written as a sequence of functions the method is cheaper by a value or two. Write the sequence if you're already in a framework that sequences functions. Don't adopt a framework for that saving.
Guard clauses and early returns you don't want to invert	This shape is where extraction is stuck and a flow isn't. Three in four of these methods came apart as the methods stand. If the choice is inverting your guards or letting a framework end a function at the return, this is the case for the framework.
An if or switch whose arms each do a lot, with exits inside the arms	A decision function with a flow per arm takes the method apart where a single-exit piece can't.
A giant switch of short cases, an array literal, a builder chain	The method is a table. Nothing splits a table and nothing should. Leave the table, or move the data out of code.
A long loop body with a break or return in the body, a try with resources	Nothing splits this method today, by extraction or by injection. Redesign the method, or leave the method and say why.

The one line to take away: function injection takes apart a bit over one stuck method in five, and nearly all of the methods function injection wins are early returns and pipelines. If your long methods are neither, function injection has nothing for you. What the study has for you instead is the table above: a long method is now one of a handful of shapes, each with a known fix or a known reason there isn't one, and the programme below is about making the tools say which.

Where injection did worse, and what to be careful about

Every failure is published. Where both extraction and the injection split have a plan, the injection split's worst seam carries more values than extraction's widest piece for 4.5% of methods, 4,993 of them, each method listed. The injection split also cuts more: more functions than extraction makes pieces for two thirds of methods. And the seam comparison leans towards injection by definition, since a function's seam doesn't count the method's parameters and a piece's width does.

"Stuck" means stuck under SinewSlim's rules: one exit, one return value, at most five parameters a piece. An IDE can extract a run with an early return by returning a flag the caller tests; SinewSlim doesn't search that form of extraction. Nobody wrote any of this code for function injection, so a plan is what the split would cost, not what anyone paid. And I created OfficeFloor and both tools, and have a commercial interest in OfficeFloor's adoption, which is why the sample was drawn by someone else's seed, the costs were fixed at or before registration, and the hypothesis was written down where the data could refute the hypothesis. The data did.

What's next

Three follow up studies to consider, each one a change to the tools, each one narrowing what the next has to explain, each registered the way this study was: a dated commit of the plan and the seed in a public repository before the sample is drawn, with scripts anyone can rerun. I'm a tool and framework developer trying to understand how software behaves, not an academic. The repository is the registration.

1. The classes become rules in the tool. The re-reading of the 9,059 methods used explicit thresholds: a switch whose cases are all three lines or fewer is a flat table, a chain of four or more calls is a builder, eight or more arguments is a long argument list, a jump is placed by the loop or try that contains the jump, and a data-coupled method is marked by the first limit at which a plan appears. Those rules go into SinewSlim, so a method the split can't plan gets a class and the advice that fits the class: leave this table where it is or move the data to configuration, extract this case, extract this loop body with the jump as a status result, group what this stage produces. Two tests: a fresh sample drawn the same way gives the same class shares, within this study's intervals; and reviewers agree with the class and the advice, class by class, with the tables first, because if reviewers don't call a table a long method, the trigger changes.
2. Each class gets the change that reaches the class, and what's left is the definition of a god method. A jump inside a loop, try or switch (1,128 methods): the splitter learns named outcomes, so the break, continue or return becomes a named exit of the function, wired in configuration. An if whose arms pass values on (267 methods): the arms become functions with the value as the flow's argument. Data coupling (3,237 methods): the limit of five is swept from three to ten over the whole population, because a higher limit moves the other categories too. Each change is tested on the methods already listed and read by two numbers: how many of the class now split, and whether what came out got denser, since a split that slims by growing denser hasn't helped. What remains when every class has had the change that reaches the class is a method over the cap that no split and no rule-following rewrite takes apart. That's a definition of a god method with no human judgement in it, and the hypothesis is that the remainder is under one long method in a hundred, dense logic, and the one place the notice should say "redesign".
3. The same measures on AI-written code. Everything here predates assistants. The third study draws the same kind of sample from code written after assistants were in general use and compares the long share, the stuck share, the class mix and the remainder against the figures here, which are the baseline. What the measures don't say, and I'll keep saying so: nothing about how methods couple to each other or whether the code changes well. They confirm decomposition, and only that.

Run it yourself

Everything is a script in long-method-slim-study, and every number in the paper is generated from the committed analysis.

If you find a method where the split does worse that isn't in the list, or a reason the split fails that isn't in the table, I want to hear about it.

What extraction cannot slim: a study registered before the data

Some long methods can't be fixed by extracting methods. Early returns, values that change on every branch, and results that need more than one return value all get in the way. I believe a framework that injects functions and sequences them can take apart many of those methods. I created that framework, OfficeFloor, so my belief counts for nothing until it's measured. This post describes a study that measures it on 580 open-source Java repositories, as they stood before AI coding assistants. The hypotheses and the rules for reading them were committed before any repository was scanned.

The question

In What reviewers call a Long Method is a length, a method reads as a Long Method from 26 code lines. The usual fix is Extract Method: lift pieces out until every piece, and what's left, fits under 25 lines. SinewSlim searches for the cheapest way to do that, pricing each cut by what crosses it (how SinewSlim prices a split).

For some methods there's no such way at all. A return can't leave an extracted piece. A piece can return only one value, and a record to carry more is a cost of its own. Some methods are knotted together so tightly that every cut is blocked. This study calls those methods stuck.

Function injection cuts differently. Each piece becomes a function the framework calls. The framework supplies its arguments, so nothing is passed in by hand. A function can hand on any number of values. An early return becomes the end of a function, followed by a flow. An if can become a decision with a flow per branch. OfficeFloorSlim searches for the cheapest split of that kind, with costs set before this study and described in its design.

So the question is: of the long methods extraction can't slim, how many can function injection take apart?

What a developer would actually do

Nobody would rewire a method into functions when extracting one method would do. Nobody would insist on functions too short to need it either. The study prices the realistic mix, which I call the combined split: functions where the flow divides, with extracted methods inside a function where its body is still long.

cost(combined) = injection cost of the functions        (values carried + 1 per function + 1 per flow)
               + SinewSlim's cost of the methods extracted inside them

the plan       = the lowest sum;  on a tie, fewer extracted methods;  then fewer functions

The whole method as one function, slimmed by extraction alone, is always one of the candidates. So wherever extraction works, the combined split works too, and it never costs more than extraction plus 1. That holds by construction, so the study doesn't report it as a finding.

The hypotheses

Each stuck method is put in one category, tested conventional first, so function injection only gets a method nothing simpler could fix:

Category	The stuck method…
2	slims by extraction if records may carry several values back
1	otherwise, slims by extraction if its jumps (return, break, continue) are ignored
3	otherwise, has a plan under the combined split: only function injection takes it apart
4	has no plan from either

• H1 (rescue), confirmatory. Category 3 is at least a quarter of the stuck methods, and at least 30 of them. The bar was fixed on 31 October 2026, before any scan. Read from the 95% interval of the population estimate: supported if the whole interval is at or above 25%, refuted if it's all below, inconclusive otherwise.
• H2 (improvement), an estimate. Of the long methods extraction can slim, how often does the combined split choose function injection and cost less? It's reported with its interval and no threshold. Ties are counted apart, because the tie-break favours injection.

What I'd already seen

A plan registered before the data has to say what was seen before it was written. I'd run the combined split on one repository: OfficeFloor's own. There it rescued 12 of 119 stuck methods, about 10%, well under H1's quarter. Of the 327 long methods extraction slims, it chose injection and cost less for 95 (29%). That 29% is why H2 has no threshold: any share I set after seeing it would test nothing.

So the one repository I've seen points against H1. I still expect code written by many hands, before AI assistants, to show more methods that only injection can take apart than my own framework's code does. That's my expectation, and the study can refute it. It's in the plan, dated, before the sample was drawn.

The sample

• Drawn by an independent tool. open-source-repository-sampler draws a seeded, stratified random sample of GitHub repositories. The seed, 20261101, was fixed in the plan, and the study's scripts refuse any other.
• Before AI coding assistants. Each repository is pinned to the newest commit on its default branch before 1 December 2020. That's six months before 1 June 2021, which was itself before GitHub Copilot's technical preview opened.
• Three popularity tiers, drawn equally: over 5,000 stars, 1,000 to 5,000, and 200 to 999.
• Large enough to have methods worth reading: at least 50 functions in at least 15 files. Repositories owned by me or by OfficeFloor are excluded.
• Production code only: every .java file, leaving out tests, build output and generated code.

The draw finished on 2 November 2026. Of 757 repositories drawn, 580 were usable and 177 were excluded by the criteria, with none lost to errors. The sample is committed in the study's repository, so anyone can see that nothing was hand-picked.

Guarding against myself

I created OfficeFloor, SinewSlim and OfficeFloorSlim. A study like this can be tilted in many quiet ways, so the design closes off the ones I could think of:

• The study computes no cost of its own. Every figure comes from the released tools, pinned by version and checksum: OfficeFloorSlim 0.3.0, built on SinewSlim 0.2.0. The costs were settled in those tools before the study could tune them.
• The two totals are never compared. Extraction and injection count different things, and the weight that would turn one into the other is exactly what a sceptical reader would say I picked to flatter OfficeFloor. The study compares what both measure: the worst seam, the number of parts and the largest part.
• Every figure is reported, whichever way it points: every reason the split fails, every method where injection's worst seam is larger than extraction's, and every excluded repository.
• The unit is the repository. Intervals come from a bootstrap over repositories within tiers. Per-repository medians are reported beside the pooled figures, so a few huge projects can't quietly carry the result.

The threats that remain are in the plan. It's a projection: nobody wrote this code for function injection, so the split is what it would cost, and the migration isn't counted. Loops and lambda bodies are never cut into separate functions. Adding the two costs to choose a combined plan weighs them 1 to 1. Stars measure attention, not craft.

Run it yourself

Every step is a script, run by hand, in the study's repository, long-method-slim-study.

The same long method under function injection: how OfficeFloor changes the split cost

SinewSlim prices a long method by what crosses each cut: the parameters and the return value. That formula assumes the pieces are methods the rest of the method calls. Under function injection they aren't. They're functions the framework calls in sequence, and it supplies their arguments. This post puts the two formulas side by side on the same method, shows where OfficeFloor makes the split cheaper, and shows where it makes it dearer.

Recap: the conventional formula

From the previous post, a piece extracted as a method:

seam(piece) = inputs + outputs           outputs ≤ 1 (a record costs 3 per value)
cost(plan)  = Σ ( seam(piece) + 1 )
feasible    = every piece AND the remainder ≤ 25 lines,
              no return / break / continue leaving a piece

The best plan is the one with the cheapest worst seam. If there is no feasible plan, the method can't be slimmed.

Every term in that formula comes from one assumption: the caller supplies everything. The remainder has to hold each value and pass it in, take the return value back, and decide what runs next. Function injection removes that assumption, and each term changes.

The same method, as functions

Here's the checkout method from the last post, with its pricing and charging written as OfficeFloor functions. This is a sketch, trimmed to the shape that matters:

public class Checkout {

    @Next("charge")
    public static void price(Cart cart, Customer customer, Out<BigDecimal> total) {
        BigDecimal subtotal = ...;
        BigDecimal discount = ...;
        BigDecimal tax = ...;
        total.set(subtotal.subtract(discount).add(tax));
    }

    @Next("receipt")
    public static void charge(@Val BigDecimal total, Customer customer,
            PaymentGateway gateway, Out<Payment> payment) {
        Payment result = gateway.charge(customer.card(), total);
        if (!result.ok()) {
            throw new PaymentFailed(result);    // an escalation, handled where it is wired
        }
        payment.set(result);
    }
}

Three things are different from extracting methods:

• Nobody passes cart, customer or gateway. Each function declares what it needs, and OfficeFloor injects it.
• Nothing returns. A value one function produces is a variable (Out<T>) that a later function declares (@Val). There's no single-return limit, and nothing to unpack.
• There's no remainder. @Next and the wiring decide what runs next, not a method holding the calls.

The formula, term by term

Inputs: injected values are free. Anything that comes from outside the method (its own parameters, or anything the framework manages, like gateway) costs nothing, because the function simply declares it. Only a value one of the new functions computes and a later one uses still costs. It costs 1 in every function that declares it, because each declaration is something a reader has to follow:

conventional:   inputs = every value the piece uses from before it
OfficeFloor:    inputs = only the values an earlier function computed, 1 per declaring function

Outputs: no single return, no records. A function can hand on as many values as it likes. A value isn't charged where it's produced, but where it's used: it costs 1 in each later function that declares it, as above, so nothing is counted twice:

conventional:   outputs ≤ 1, or a record at 3 per value
OfficeFloor:    any number of outputs; each is paid for by the functions that declare it

Jumps: most are no longer blockers. A return in the middle becomes the end of a function, followed by a @Next or a flow to the next one. A throw becomes an escalation, handled wherever it's wired. break and continue still block, because a loop body doesn't become a flow without spawning. The two models agree there.

conventional:   feasible only if no return / break / continue leaves the piece
OfficeFloor:    return → @Next or a flow;  throw → escalation;  break / continue still block

Branches: a new kind of cut. Conventionally, an if moves whole or its insides move. Under OfficeFloor an if or switch can become a decision function, with each branch a flow to its own function. That kind of cut doesn't exist when a remainder calls the pieces.

The remainder disappears. Conventionally the remainder must fit under 25 lines too, holding one call line per piece. Under OfficeFloor each function must fit under the cap, but there's no method left over holding the calls.

The wiring is paid for. Conventionally a piece costs its seam plus 1 for its name and call line. Under OfficeFloor a function costs its seam plus 1 for its name, and every edge between functions (a @Next or a flow) costs 1 more. Without that, OfficeFloor would come out cheaper just by leaving the wiring out of the sum. Put together:

seam(function) = values it declares that an earlier function computed
cost(plan)     = Σ ( seam(function) + 1 ) + edges

The two side by side

	Conventional (extract method)	OfficeFloor (function injection)
Seam	inputs + outputs	values declared that an earlier function computed
Outputs	at most 1, or a record at 3 per value	any number, paid for where they're declared
Cost per piece	1: a name and a call line	1 for the function, plus 1 per edge
Must fit under 25	every piece and the remainder	every function
return mid-method	blocks the cut	ends a function: @Next or a flow
throw	moves with the code	an escalation
break / continue	blocks the cut	blocks the cut
if / switch	moves whole	can be a decision function with a flow per branch
Shape of the result	a tree: the remainder calls the pieces	a graph: the framework sequences the functions

The worked example, priced both ways

Under OfficeFloor there's no remainder, so the end of the method (building the receipt and mailing it) becomes a third function, receipt. The guard clause moves into price, where an empty cart goes down its own flow instead of returning.

Piece	Conventional seam	OfficeFloor seam
pricing	cart, customer in; total out → 3	cart, customer injected → 0
charging	gateway, customer, total in; payment out → 4	total declared; customer, gateway injected → 1
receipt	stays in the remainder	total, payment declared; cart, customer, mailer injected → 2
worst seam	4	2
total cost	(3 + 1) + (4 + 1) = 9	(0 + 1) + (1 + 1) + (2 + 1) + 3 edges = 9

The three edges are price → charge, charge → receipt, and the empty-cart flow. If the payment failure needs a new handler wired for its escalation, that's one more edge, making 10.

So the worst seam halves, from 4 to 2, but the total stays about the same. Here OfficeFloor doesn't make the method cheaper overall. It spreads the cost evenly, so no single function is hard to follow, and it pays for that with wiring and a third function the conventional plan didn't need. The bigger change is the guard clause. Conventionally, that early return Receipt.empty() pins the top of the method to the remainder. Under OfficeFloor it becomes a flow, and the method's structure stops fighting the split.

Where OfficeFloor costs more

It isn't free, and a comparison that only shows savings isn't worth much:

• Wiring. Every function is a node someone has to wire, and every @Next or flow is an edge to keep correct. A conventional extraction is one call line in a method you're already reading.
• Values carried a long way. A value produced early and used by several later functions is declared in each one. If a method passes a lot of computed state from step to step, the OfficeFloor seams don't shrink much, and the wiring is added on top.
• Loops. A loop whose body is too long still has to be split inside the loop, the conventional way.
• Getting there. In a Spring codebase, the method's beans have to be made available to OfficeFloor, transactions need a boundary, and exceptions need handlers. That's a migration cost the seam formula doesn't count, and an honest comparison has to report it beside the seam.

Why I'm keeping the two formulas apart

SinewSlim already has a "framework reading" that re-weights its formula: passed values are free and outputs are unlimited. It's a useful first look, but it's still the conventional search with a remainder calling pieces. It can't express "this if becomes a decision function with two flows", however it's weighted.

So the OfficeFloor model is becoming its own tool, OfficeFloorSlim. It reads the same facts as SinewSlim, but it searches differently: it partitions the method's control flow into connected functions, rather than lifting pieces out of a remainder. SinewSlim stays a neutral measure of conventional code and never mentions OfficeFloor. The comparison is computed in OfficeFloorSlim, beside SinewSlim's number, so neither one is tuned to flatter the other.

The numbers in this post come from one method I chose to show the difference. Whether the difference holds across real codebases is a question for measurement, not for a blog post. That's the empirical study now under way: the same applications built with Spring and with OfficeFloor, measured as they grow. The paper will carry the method and the statistics, including every case where OfficeFloor comes out worse.

SinewSlim: what it costs to make a long method short

A long method is easy to find. Knowing whether it can be fixed is the hard part. SinewSlim answers that with one small formula: count what crosses the seam when you cut the method in two. This post walks through that formula from a developer's point of view, with a worked example, what the tool does with the answer, and where it stops.

Where the 26 comes from

I'm not going to re-argue what a Long Method is. That was settled in the study behind What reviewers call a Long Method is a length. Plain length, at 26 code lines, picked out the methods reviewers flagged as Long Methods better than anything else I tried. Complexity, coupling and variable counts all came in below it. So a method of 26 code lines or more is long, and that is the trigger.

Once that's settled, "is it long?" stops being the interesting question. The useful question is: what does it cost to make it short? Some long methods are just a sequence of steps, and splitting them takes a few minutes. Others have the same handful of variables touched on every line, and there's no clean place to cut. Both are 40 lines long. They are not the same problem.

The sinew

When you extract a run of statements into its own method, every variable crossing the boundary becomes interface:

• used inside the run and set before it → a parameter
• set inside the run and used after it → the return value (and Java gives you one)
• used only inside the run → nothing; it moves with the code

That data crossing the cut is what I call the sinew. A long method is a muscle grown too big. You don't want to cut through the sinew; you want to slim the method by moving whole runs of statements out where the least sinew crosses.

The formula

For one extracted piece, the cost of its seam is what crosses it:

seam(piece) = inputs + outputs

Every parameter costs 1 and the return value costs 1. A plan for a method is a set of pieces, and it costs:

cost(plan) = Σ ( seam(piece) + 1 )      the +1 is the new name and call line

A plan only counts if it actually fixes the method. Every piece, and what's left of the original method (the remainder), must end at 25 code lines or fewer.

Among the plans that work, SinewSlim picks:

1. the smallest worst seam: the plan whose most expensive cut is the cheapest;
2. then the fewest pieces;
3. then the smallest total cost.

The worst seam comes first on purpose. One extracted method that takes five parameters is worse for the next developer than three that take two each. The worst seam is the method's slim cost, the single number SinewSlim reports.

What a piece is allowed to be

Java puts limits on what a piece can be, so the formula comes with rules. With the defaults:

Rule	Default	Why
Return values per piece	at most 1	Java has one return
Parameters per piece	at most 5	a hard ceiling; more than that is not a fix
Jumps leaving the piece	none (a trailing return is fine)	a return, break or continue in the middle can't move into another method
Smallest piece	3 lines	below that a call saves almost nothing
Largest piece	25 lines, after its own pieces are out	the piece must be under the cap too

Two refinements are worth knowing about:

• A soft parameter limit (optional). Set soft_inputs: 3 and each parameter beyond three costs 2 extra. A 4-parameter piece then costs 6, so the search takes it only when every 3-parameter route costs more.
• Records. If every way to fix the method needs a piece returning two values, SinewSlim offers a record instead, at 3 per value. That reflects what the developer pays: a record type to name, the call, and an unpacking line per value left behind.

A worked example

Here's a checkout method, abbreviated. The real one is 38 lines, mostly in the pricing.

public Receipt checkout(Cart cart, Customer customer, PaymentGateway gateway, Mailer mailer) {
    if (cart.isEmpty()) {
        return Receipt.empty();
    }

    // pricing: 14 lines of subtotal, loyalty discount and tax
    BigDecimal subtotal = ...;
    BigDecimal discount = ...;
    BigDecimal tax = ...;
    BigDecimal total = subtotal.subtract(discount).add(tax);

    // charging: 8 lines
    Payment payment = gateway.charge(customer.card(), total);
    if (!payment.ok()) {
        throw new PaymentFailed(payment);
    }
    ...

    Receipt receipt = new Receipt(cart, total, payment);
    mailer.send(customer.email(), receipt);
    return receipt;
}

Price the two obvious cuts:

Piece	Parameters	Returns	Seam
pricing	cart, customer	total	2 + 1 = 3
charging	gateway, customer, total	payment	3 + 1 = 4

subtotal, discount and tax are used only inside the pricing, so they move with it and cost nothing. The throw is fine: an exception leaves the new method the same way it left the old one. Extracting both pieces leaves a remainder of around 18 lines, so the plan works. Its slim cost is 4 and its total cost is (3 + 1) + (4 + 1) = 9.

Now notice the guard clause at the top. That return Receipt.empty() is in the middle of the method, so any run that includes it can't be extracted. Here it's harmless, because it's short and stays in the remainder. When the early returns are spread through the long part of a method, though, they block every cut.

What SinewSlim tells you

Every method gets one of three answers:

• Under the cap. Nothing to do.
• Slimmable, with the pieces, what each takes and returns, and the cost. In the IntelliJ plugin each piece has a button that runs the IDE's own Extract Method and asks you only for a name.
• Not slimmable, with the reason. The tool lifts its limits one at a time to find which one blocks: two or more return values, too many parameters, jumps, one statement longer than the cap by itself, or a method so long that it needs splitting in two passes.

The third answer matters most. A method that can't be slimmed is a design problem, and every change to it makes it harder to take apart later. On OfficeFloor's own code (21,994 methods), 106 methods can't be slimmed, and for 79 of them the reason is jumps: early returns, or a switch full of returns.

There's a fourth case, reported as a warning. If every piece writes to the object's fields or calls the class's own methods, the method can be split, but nothing actually leaves the class. That's a god method, and the class is what needs fixing, not the method.

What it doesn't measure

Being straight about the limits:

• It costs interface, not meaning. A cheap seam can still be the wrong thing to name. If a piece doesn't make sense as a method, skip it and the tool finds the next plan.
• Fields are not counted as interface. A piece that only reads fields is free in the formula, but it's tied to the class. The tool reports that as the piece's binding (static, static if the fields are passed in, or instance) rather than folding it into the cost.
• It reads syntax, not types. There's no symbol solver, which is why it's fast enough for a git hook, and why a few edge cases need the IDE to finish the job on splitting.

Trying it

SinewSlim is on GitHub, Apache 2.0. It runs as a command-line scan of a whole codebase, as a GitHub Action that reviews the methods a pull request touches, as a git hook, and as an IntelliJ plugin. One .sinew-slim.yml drives all of them, so they never disagree about a method. When it's set to block, it only blocks a change that pushes a method over the cap or makes a long method longer, so it can be switched on in a codebase that already has long methods.

What reviewers call a Long Method is a length

I ran a study to test an idea behind OfficeFloor: that coupling is what separates a god class from a merely complicated one. The idea failed the test. What the data showed instead was much simpler and more useful. When professional reviewers call a method a Long Method, they are responding to its length, and the line sits at about 26 code lines. This post explains the study for developers: what I tested, what failed, what came out of it, and what it means for the code you review.

The paper is What reviewers call a Long Method is a length. It has the full method and statistics. This post covers what matters if you write and review code.

What I set out to test

An earlier study of mine (the companion paper) flagged a class or method when its complexity was unusually high for its own codebase. It found where the complexity was concentrated, but it couldn't tell two things apart:

• a god unit: a class or method that directs everything around it and also holds the logic;
• a complex algorithm: a class or method that is hard inside, but just processes what it's given.

Both look complicated. The difference, I thought, was in the coupling. A method that hands data on to lots of other code is directing traffic. A method that receives data and works on it is a leaf. So I proposed weighting complexity by what a unit hands on minus what it receives, so that leaves are set aside and the traffic directors stand out.

This idea matters to me personally. OfficeFloor is built on taking data off the call chain. If coupling explained god units, that would have supported the framework's premise. So I pre-registered the test: the measure, the data, the pass mark and the statistics were written down and committed before any coupling was measured on the data used to judge it. That way I couldn't adjust the test after seeing which way it went.

The data

The labels come from MLCQ, a public data set in which professional developers reviewed classes and methods from Java open-source projects and said whether each one was a code smell, such as a Blob (god class) or a Long Method. I measured 520 of those repositories, plus 500 fresh Java repositories and 73 systems from the Qualitas Corpus, which carry a second set of human god-class labels.

The repositories were split in half before anything was measured. One half, explore, is where choices are made. The other half, confirm, is only used to check them. A number chosen on one half and checked on the other is far less likely to be a fluke of the data.

Agreement is reported as MCC (Matthews correlation coefficient). If you haven't met it: it scores how well a yes/no rule matches the labels, from 0 (no better than chance) to 1 (perfect). Unlike plain accuracy, you can't score well by always saying "no" when smells are rare. For a sense of scale, machine-learning classifiers trained on these same labels reach a median MCC of about 0.81 for Long Method.

The idea failed

Against the reviewers' god classes, weighting complexity by coupling did not beat complexity alone. The difference was −0.041, and the plausible range ran from −0.130 to +0.054, so no difference was shown either way. The test was also underpowered: MLCQ didn't have enough repositories with a reviewed god class to show a small effect.

What was clear went against the idea:

• Without picking a threshold, the coupling-weighted form ranked god classes worse than complexity alone.
• Weighting by plain size (the number of methods in the class) beat weighting by coupling, by a margin the data could resolve. A god class, to these reviewers, looks more like a big class with one complex method than a hub of coupling.
• Only one part of the idea held up: among complex methods, leaves were called smells less often. Even that narrowed later, as you'll see below.

I'm reporting this plainly because it's the result I didn't want. A study that can only confirm its author's framework isn't worth reading.

What the data did settle: a Long Method is a length

MLCQ keeps every individual review, not just the majority verdict. Once the registered test was done, I looked at what the reviewers actually do. Here are 3,054 Long Method reviews by 26 reviewers, grouped by the method's code lines (blank lines and comments not counted):

Code lines	Called a Long Method (calls other project code)	Called a Long Method (leaf)
1–10	1.0%	0.4%
11–25	24.3%	17.4%
26–50	81.6%	80.0%
51–100	94.0%	94.1%

There's a step at about 25 lines. Below it, most reviewers let a method go. Above it, four out of five call it long. Three things stand out:

• It's the same line for everyone. Each of the ten reviewers with at least ten Long Method calls has a best cutoff between 17 and 34 lines (median 21), whichever project they were reviewing. The line varies a little from reviewer to reviewer, but not from codebase to codebase. That's why my earlier "unusual for this codebase" rule could never match it.
• Leaf or not doesn't matter. At 26–50 lines, a method that calls nothing else in the project is called long 80.0% of the time, against 81.6% for one that does. Reviewers judge the length, not the coupling.
• Where leaves do get a pass, it's narrow. Among the methods that cognitive complexity flags, the leaves are called long less often (63% against 83%), at about the same median length. Reviewers are a little more forgiving of a branchy method that calls nothing else in the project. That's the only exemption the data support.

Why 26

I treated the cutoff the same way as everything else: chosen on one half, checked on the other. On the explore half I tried nine round cutoffs (10, 15, 20, 26, 30, 40, 50, 75 and 100 lines). 26 scored best there (MCC 0.715, against 0.710 at 20 and 0.681 at 30).

On the confirm half, which played no part in the choice, "26 code lines or more" flags 131 of 1,033 reviewed methods. 103 of those are ones the reviewers called long, and it finds 82% of all the methods they called long. That's an MCC of 0.777, from one number with no training. The classifiers trained on these labels sit around 0.81.

Don't read too much into the exact 26. On the confirm half the score is flat from 20 lines (0.761) to 30 (0.778), and has fallen by 40 (0.644). The honest summary is "mid-twenties". 26 is the cutoff the procedure picked, and it's as good as anything in that range.

Nothing inside the method does better

The obvious objection is that length is a crude proxy. Surely the real thing is how many variables you have to keep in your head, or how tangled the data flow is? I tested that too.

• 34 measures built from the method's variables: how many are live at each line, counts of locals, parameters and fields, and the data flow from inputs to calls. Every one did worse than plain length, by a margin the data could resolve. The best reached 0.673.
• The cost of splitting the method: the parameters and return values its pieces would have to pass, the formula SinewSlim now uses. It came close (0.764) but didn't beat length. Among long methods it didn't pick out which ones the reviewers called long, either.

So nothing measured inside a method's body tells you which long methods reviewers let through. They are counting lines, and a line count is the right detector for what they call a Long Method.

What this means for you

• You can stop arguing about the threshold. A cap in the mid-twenties of code lines matches what professional reviewers call a Long Method. It doesn't need to be tuned per project, and it doesn't need a complexity metric alongside it.
• "Is it long?" is the boring question. Once length is settled, the useful question is how hard the method is to bring back under the cap. Two 40-line methods can be very different problems: one splits into three clean pieces, while the other has the same five variables on every line.
• The cap is about people. 26 lines is a limit of human reading. Code that agents write and maintain doesn't have to respect it for the agent's sake, but people still review it. The cost of keeping it readable depends on how the code is structured, and that's where architecture comes in.

That second point is why I built SinewSlim (link to the SinewSlim post): it takes 26 as given and prices the cut. The third point leads to the follow-up, which compares the same cut under conventional calls and under OfficeFloor's function injection.

Limits

• The length finding is exploration, not a registered test. It came after the registered analysis had been read. The confirm half is an independent check of the choice among the nine cutoffs, but I picked those nine after looking at the reviews.
• Java open source, and one data set. MLCQ's reviewers are professional developers, but they're reviewing open-source Java, and half the confirm repositories sit under ten owners. Other languages and closed codebases may differ.
• Conflict of interest. I created OfficeFloor, and a positive result would have suited me. It came out negative, and the paper says so.

Everything needed to re-run it is public: the plan with its dated amendments, the samples, the converted labels and the scripts, with the outputs and their digests. A replication doesn't need anything from me.

What must AI think of us?

So us humans have a limit of 26 lines before we consider it "big" or "godly". An AI with a 1M context minus some for processing overhead, can consider about 50,000 to 75,000 lines of code.  It leaves me thinking, are we humans the "junior" developers trying to code review the "senior" AI developer?

Furthermore, I'm thinking we need to be building the foundations on which we can trust AI, such as the mathematics behind sinews to mathematically restrict AI from eroding the system.

Sinews: catching a god class while it is still small

The god class experiment found that complexity concentration finds god classes, but cannot tell a god class from a complex algorithm. This post is about the idea I think tells them apart, the sinew, and the experiment that has now started to test it. There are no results yet, only the idea, why it matters, and how it will be judged.

The god class experiment is finished and published on Zenodo. Its question was can we find god classes/methods by complexity concentration (from the understand complexity is conserved Conserved Amount, Negotiable Placement). The answer was that it nearly can but flags too much. Some were god classes/method. The others were classes that correctly compute complex algorithms.

So concentration is the right signal, but it is only half of one. It says where the complexity is. It does not say whether that place is healthy.

Two kinds of concentration

Think of a complex algorithm and a god class side by side. Both score high on cognitive complexity. Both stand out in their repository. The difference is in how they sit in the system.

The algorithm receives its inputs, works on them, and hands back a result. Data flows in and stops there. It is a leaf.

The god class is the opposite. It receives a request, and then it reaches out: it loads this, checks that, builds the other, passes the owner and the form and the clock and the result to half a dozen collaborators, and decides what happens next. Data flows in and fans out again, carried on the calls. It is a junction.

That is the distinction I want to measure, and the name I have for what makes the difference is a sinew.

What a sinew is

A sinew is data coupled to the control flow: data that reaches the code that needs it only by being passed down the call chain, method to method. The more data rides on the control flow, the stronger the sinew.

Here is the shape, in a deliberately ordinary Spring style handler:

@PostMapping("/owners/{ownerId}/pets")
public String addPet(@PathVariable int ownerId, PetForm form, BindingResult result, Model model) {
    Owner owner = owners.findById(ownerId);
    validate(owner, form, result);
    if (result.hasErrors()) {
        return populate(owner, form, model);
    }
    Pet pet = build(owner, form, clock.now());
    owners.save(owner, pet);
    notify(owner, pet, model);
    return "redirect:/owners/" + ownerId;
}

Nothing here is bad code. But look at what travels. owner is passed to four calls. form to three. model and result are carried along so that something further down can write into them. Every method on those paths has the data in its signature, whether it uses all of it or only passes it on.

The name comes from the body. A sinew is what ties the muscle to the bone: it is what makes things move together. Data threaded through a call chain does exactly that to code. The methods on the path cannot move without each other.

Four harms

Strong sinews make code hard to change, in four ways:

1. Ripple. Add a field, a parameter, a new piece of context, and every method that carries it changes, including the ones that only pass it on.
2. Rigidity. A step cannot be inserted, removed or reordered without re-plumbing the signatures either side of it.
3. Comprehension. To know where a value came from or where it goes, you follow the whole path.
4. Attraction. Data in scope invites logic.

The fourth is the one that matters here. A method that already holds most of the data a change needs is where the next change is easiest to put. It does not have to be a decision. It is the cheaper path. So the next rule goes there, and the one after that, and the method that held the data now holds the logic too. Complexity collects where the data is.

Gravity

This is why I think of it as gravity. A junction with strong sinews has mass: it holds the data, so it attracts the logic. The logic it attracts brings more data with it, more parameters, more collaborators, more things passed on. That is more mass, and more attraction. The pull grows with what it has already pulled in.

And the pull works against the way out. The cost of refactoring a junction is the cost of cutting its sinews: every path the data rides has to be re-plumbed. So the bigger the junction gets, the more expensive it is to break up, and the more likely the next change is to land in it rather than around it. Past a certain point it is a black hole. Everyone knows it is a god class, nobody can afford to take it apart, and it keeps growing.

That is the reason to want to see it early. A junction that has just started to attract logic is a few signatures and a few calls. Refactoring it is an afternoon. The same junction a year and forty features later is a project. If a measure can say which concentrations are junctions, then it can say, while it is still cheap, which ones are going to keep growing.

Measuring it: coupling divergence

The measure began as coupling divergence: per method, the coupling going out against the coupling coming in. Coupling here is counted from what rides on the control flow. For a method with p parameters that makes calls into its own project, passing a(c) arguments on each call c:

• in = 1 + p (the call that reached it, plus the data that came with it)
• out = the sum over its calls of 1 + a(c) (each call it makes, plus the data it sends)
• d = out − in

That gives each method a role, by analogy with a pipe system:

d	role	reading
greater than 0	junction	creates and directs flow: hands on more data than it receives
0	pipe	passes data through
less than 0	catchment	a leaf: receives data and processes it

The addPet above is a junction. A parser that takes a string and returns a tree is a catchment.

And that is the classification. Complexity concentrated in a catchment is good concentration: leaf processing doing the work, which is where the complexity of an algorithm belongs. Complexity concentrated in a pipe or a junction is bad concentration: a unit that directs the data and also holds the logic. The gravity well.

There is a picture behind this from the earlier experiments. If complexity is conserved, and an architecture only moves it rather than removes it, then each method takes up area in proportion to its complexity, and the question is where the area sits. In a healthy system most of it sits in the catchments, and the junctions stay thin. A system out of balance puts its area in junctions.

None of the ingredients are new. Tramp data and stamp coupling are in Yourdon and Constantine's Structured Design from 1979, and a sinew is tramp data seen as a path. Henry and Kafura's information flow multiplied complexity by fan-in and fan-out in 1981. Lanza and Marinescu's God Class already combines complexity with access to foreign data. What I have not found is the combination: a signed balance of what a unit sends against what it receives, used to set complex leaves aside, on a scale that each codebase sets for itself.

The experiment

The concentration divergence study asks one question:

In Java, does weighting a unit's complexity by its coupling divergence recover the units people call god classes and methods better than complexity alone, by setting complex leaves aside?

It is built the way the god class study was, and on top of it. The complexity measures, the outlier rule and the statistics are the god class study's, installed from its released commit, so every baseline number is the number that study would produce on the same class. What is added is the coupling: a JavaParser measurer with its symbol solver, which resolves each call to see whether it lands in the project's own code.

The plan was written first and tagged in git (plan-v1) before any measurement code existed. Every change since is its own dated commit, stating what had been seen when it was made.

The things I most want to get right:

• People decide, not tools. The primary oracle is the MLCQ data set (Madeyski and Lewowski): professional developers reviewing real Java code and saying, without being given a definition, whether a class is a Blob or a method is a Long Method. PMD's GodClass is in the study too, but it already contains a coupling measure, so agreement with it would be partly circular. Only a person can say "this is a god class, that is just a hard algorithm".
• The base signal is chosen without the factor. On the explore half of MLCQ, the complexity signal is chosen by how well it does on its own. The divergence factor is never consulted, so it cannot pick a signal it happens to win on. The verdict is read once, on the confirm half.
• The rival explanations get their own arms. A class's divergence is a sum over its methods, so a bigger class tends to have a bigger divergence. If weighting by divergence helps, it could just be weighting by size. So the same weighting by the class's number of methods, which carries no coupling at all, is measured beside it. And the factor does two things at once, it exempts catchments and it amplifies junctions, so each is tested on its own. If the gain all comes from amplifying junctions, the claim that setting leaves aside is what helps is not supported, even if the headline is positive.
• More than one way to count. Three definitions of coupling run through everything: the one above, where a call is itself coupling; one where only the data counts; and one after Alan Kay, where the first item of a call is the message and coupling starts at the second.
• More than one population. A fresh random sample of Java repositories on a new seed (seeds 1 and 2 are used and seen), scored against the tool oracles; and Fontana's God Class, 420 classes judged by hand by a different team on the Qualitas Corpus, as a replication.

And there is a competing expectation I have to write down, because I saw it first. On the AI evolved petclinic code from the earlier experiments, it was the outgoing data on its own that carried the signal, and the balance against the incoming added little. If that holds here, what matters is how much a unit sends, and the sinew's balance is the wrong half of the idea. The plan reads that as its own outcome, not as a failure to be explained away.

As of today, the plan is registered, the measurer is built and validated on material already seen, the MLCQ repositories are being measured at the commits their reviewers labelled, and the fresh sample has been drawn. No result against any oracle exists yet.

What this experiment does not test

It looks at one checkout at a time. It asks whether sinews tell bad concentration from good, at the commit the reviewers labelled. It does not ask whether a junction found today grows into a god class next year.

That is deliberate. Before asking whether something shows early, there has to be a definition of the thing that holds up. If coupling divergence does tell god units from complex leaves, the next study takes it into git history and asks the question this post is really about: does a junction with strong sinews attract the next changes, and does it show while it is still small enough to refactor? That one will be registered on its own, judged by what actually happens to the code, not by agreement with another detector.

Where OfficeFloor comes in

I created OfficeFloor, and the sinew idea came out of building it, so I should say plainly where the interest is and how far the claim goes.

Most web frameworks are what I have been calling mutative. The framework gives you one hook per request: a controller method, a handler, a route function. Everything after that is yours to design. The control flow, the logic, which data goes where, all of it starts in that one method. That is a lot of freedom, and freedom is fine when someone is exercising judgement about it.

AI does not seem to. In the earlier experiments, and in others' work, AI tends to concentrate. Zhang, Wen and Tempero found that LLM generated object oriented designs put more of the burden into fewer classes, with the largest class holding a bigger share of the code, while smell detectors registered nothing unusual. He and colleagues found SonarQube's cognitive complexity rose and stayed up in projects after they adopted Cursor. A single handler hook with the data already in scope is exactly the place attraction works on. It is the junction, handed to you on the first line.

OfficeFloor separates the two graphs. The control flow between procedures is configured, and the data is injected. A procedure declares what it needs and what it produces, and does not receive it from whoever called it. Sketched, the first steps of the same handler:

public class AddPet {
    public static void loadOwner(@HttpPathParameter("ownerId") int ownerId,
            OwnerRepository owners, Out<Owner> owner) {
        owner.set(owners.findById(ownerId));
    }

    @Next("invalid")
    public static void validate(@Val Owner owner, PetForm form) { ... }

    public static void build(@Val Owner owner, PetForm form, Clock clock, Out<Pet> pet) { ... }
}

No procedure passes owner to the next. It is a variable that each one that needs it asks for. So in the flow layer, between procedures, no data rides on the control flow, and a sinew cannot form there by construction. Inside a procedure it is ordinary Java, and sinews can form exactly as they do anywhere else, but they cannot reach past the procedure.

So here is the consideration, loosely, and not yet proven by anything. If sinews are where complexity concentrates into god classes, and if AI concentrates code in architectures that hand it one hook and a scope full of data, then an architecture that constrains sinews might be one that contains AI's tendency to concentrate. Not by stopping it from writing complex code, but by not giving the complexity a junction to collect in.

It also has to survive what I have already seen. On the petclinic runs, complexity concentrated about as much in OfficeFloor as in Spring: the Gini coefficient of method complexity rose from 0.23 to 0.34 in Spring and from 0.22 to 0.35 in OfficeFloor. What differed was where it sat. OfficeFloor started with 64% of its complexity in catchments, against Spring's 42%. So the claim, if it holds, is not that OfficeFloor code concentrates less. It is that its concentration lands in leaves rather than junctions, the good kind rather than the kind with gravity. That was one small application evolved by agents, the sixth way of measuring the same run, and it shaped the hypothesis rather than testing it.

That is three ifs, and the experiment that has started tests only the first. It samples repositories at random and does not compare frameworks. The OfficeFloor part is a direction, not a finding, and it has a trap I intend to stay out of. OfficeFloor code will behave differently under these measures, by design. If I only explain that difference after I see it, "OfficeFloor works differently" can explain anything, and the theory stops being testable. So when OfficeFloor code is measured, what it should look like will be written down first.

The short version

Complexity concentration finds god classes but cannot tell them from complex algorithms. The sinew is my candidate for the difference: data threaded down the control flow, which holds code together so that it cannot move apart, and which attracts the next piece of logic to wherever the data already is. A unit that sends out more data than it receives is a junction, and complexity in a junction is the kind that grows, pulling in more complexity and more coupling until it is too heavy to refactor. Complexity in a leaf is just an algorithm. A pre-registered experiment has started to test whether that distinction recovers the classes and methods people call god units better than complexity alone, judged by human reviewers, with size and fan-out given every chance to explain it away first. If it does, the next step is to see whether a junction shows early enough to cut before its gravity wins, and after that, whether an architecture that keeps data off the control flow keeps AI from building the junctions at all.

The plan, its amendments and the harness are public in the repository, with the commits that show when each was made.