A Fortnight Measured, Not Recalled
We publish these notes from a commit log rather than from memory, and the difference shows up in what gets reported. 180 commits across 20 repositories in eight days, and the three things that turned out to matter were not the three anyone would have named.
These notes are assembled from a commit log, not from a conversation about what we remember doing.
That sounds like a small methodological detail. It changes the content substantially, and the difference is worth one edition’s worth of explanation.
180 commits across 20 repositories in the eight days to 26 September. The log they came from now holds 4,677 rows.
What memory reports
Ask any team what they did in the last fortnight and you get a predictable distortion, in three directions.
The most recent thing is over-represented. Whatever happened on Thursday feels like the fortnight. Work from ten days ago has already compressed into “and some other things”.
The most difficult thing is over-represented. A two-day fight with a build system is memorable. Four days of steady, uneventful delivery is not, and the ratio in the retelling is the reverse of the ratio in the time.
The work that went smoothly disappears entirely. Nobody recalls the thing that worked, which means the report systematically describes a harder fortnight than the one that happened.
A commit log has none of those biases. It also has none of the judgement — it will tell you 180 things happened and not one word about which mattered.
So the method is: take the count from the log, take the significance from reading it. The log decides what is in scope; a person decides what leads.
What the log said this time
| Division | Commits |
|---|---|
| Content operations | 43 |
| Other projects | 35 |
| Potentialz | 34 |
| Cloud Geeks | 18 |
| Cosmos Web Tech | 15 |
| Ash Ganda | 14 |
| GTS | 14 |
| Awesome Apps | 7 |
The distribution itself is the first finding, and it is the kind only a count produces. Content operations and platform work took more than half the fortnight. If you had asked us, we would have said it was a client-delivery fortnight, because client work is what you remember.
Three things that mattered, none of them obvious
A control that had never been able to fail. A duplicate-upload check had been running for weeks and blocking nothing, which read as a clean pipeline. It was reading a companion file that one whole category of item never writes, so it approved everything. Zero blocked was not evidence of anything. That one is written up on ashganda.com.
An upgrade that was a downgrade. A shared component and our copy of it had both moved forward, each gaining something the other lacked. Copying the newer one over ours took the upstream fix and discarded three local ones — caught only because a test compares the two implementations against the same inputs.
244 pages that said the same thing. An audit across every site found 102 groups of posts with identical titles and bodies 77–98% token-identical, left over from a historical bulk run. They have been consolidated onto one canonical each, with the internal links repointed first so nothing routes through a redirect.
Not one of those three is a feature. All three are the kind of finding that only appears when somebody looks at the whole rather than at the thing in front of them.
★ Insight ─────────────────────────────────────
Reading a fortnight’s commits end to end takes about twenty minutes and it is the only way we have found to see the shape of the work. Individually each commit is reasonable. In aggregate, patterns appear that no single change reveals — three separate controls that could not fail, in three unrelated systems, in one fortnight. That is not three bugs, it is one habit, and a habit is only visible from above.
─────────────────────────────────────────────────
What went wrong
Two of our own measurements were wrong before they were right.
The link audit classified social redirect pages as commercial pages, which filled the “commercial pages with no inbound links” list with /facebook/ and /gbp/ and buried the suburb pages that were the actual finding.
The keyword-ownership check resolved a term to whichever site declared it first in a config file, rather than respecting which field it was declared in. That reported 183 violations against a site for using its own keyword. After the fix, the real number was a fraction of that.
Both were caught by the same habit that catches everything else here: the result looked surprising, so it got checked before it got reported. A number that surprises you is either a finding or a bug, and the cost of telling them apart is always lower than the cost of publishing the wrong one.
Also shipped
Scheduled publishing, which the estate did not have. None of the five sites filtered by date — every one published on a draft flag alone, so a post dated next week went live the moment it was pushed. Dated posts are now held and released on the day.
Reciprocal links between suburb pages, after finding that eight of them appeared in nobody else’s “also serving” list and had no inbound links at all.
The thread
Recent editions have been about gates that did not run, gates that fired on the wrong things, and two systems that stopped agreeing. This fortnight’s version is quieter: we measured our own estate properly for the first time and found it was 11% duplicate.
That was not hidden. It was simply never counted, and nobody who worked on any individual part of it would have had reason to.
The practical form of that, for any business: the things that go wrong at the level of a whole system are invisible from inside any one part of it. Somebody has to count the whole thing occasionally, and it will be uncomfortable the first time.
Ganda Tech Services runs web, cloud, mobile and content operations for a group of Australian brands. These notes are published every fortnight, whatever they say.