By Chason Arthur · Revision 1.0 · Updated
PHP application · Python analyzer · Git evidence
Count the change.
Test the contribution.
Carl adds comments. Chloe replaces a 500-line function with four lines. Who improved the application—and what evidence would let you say so?
Five fictional programmers. One synthetic PHP application. Ten branch commits, ten local merges and ten local pulls. No applicant data, uploads or production connector.
500 → 4Physical function lines. A formatting-sensitive size observation.
+3 / −499The actual Git diff. A closing brace survives, so the counts differ.
112 / 112 matchObserved PHP behavior. The shorter unsafe variant fails 12 cases.
Reading preferences · shared across Zyel Labs
Optional settings stay in this browser for 30 days. No account, telemetry or AWS sync.
Shared controls need JavaScript. The article and source links work without it.
01 / The question
Busy is measurable.
Useful needs a definition.
Counting commits or added lines would make Carl’s activity look much larger than Chloe’s. That says what changed in Git. It does not establish which work made the application safer, easier to change, or more useful.
This experiment works backward from a stated goal: preserve a known shipping contract while removing repetitive implementation. We construct a deliberately repetitive baseline, characterize it, perform a refactor, and try to falsify the result. The fixtures demonstrate the measurement method; they do not statistically validate a universal productivity model.
02 / A real SDK, an isolated workshop
Adapt a real library.
Keep its authorship intact.
This successor uses Webmozart Assert at commit 8a163706bbcac613733dba03f51e13b5eb1bb819, an MIT-licensed PHP assertion SDK. Its original copyright is Bernhard Schussek’s; composer metadata also credits Woody Gilk. Their unchanged SDK source and license remain in the kit. Our five fictional programmers did not write that SDK.
Ben builds a custom ShippingInput adapter around the real SDK’s type, key and range assertions. It preserves the request contract while making domain validation explicit. The isolated application is substantially reworked across the five synthetic roles; upstream library bytes remain unchanged, with the adaptation visible in application source rather than disguised as upstream work.
fixture-baseline. Each fictional change gets its own feature branch, commit, measured PHP checks and a local simulated review record. Ten --no-ff merges and ten pull --ff-only operations deliver the work into a separate review checkout. No GitHub PR, external push, public approval or production deployment is simulated as real.The analyzer traverses all reachable branch commits in fixture-baseline..HEAD. It excludes the vendor import and baseline from five-user attribution and lists merges separately. This prevents Carl or Chloe from receiving credit for thousands of imported SDK lines, or losing their branch work because only merge commits were inspected.
| Local record | Author / branch head | Merge | Pull readback |
|---|
The pinned SDK requires PHP ^8.2 with ctype, date and filter. Composer scripts and upstream development tools are not installed or executed. Only the included application tests and the SDK assertion paths used by the adapter run. This does not claim that the full upstream SDK test suite passed.
02 / Interactive contribution matrix
Change the lens.
Keep the evidence.
The values below come from the downloadable Git history, not invented dashboard totals. All five programmers work in PHP. Python powers the analyzer and is outside the sample repository.
| Programmer | Commits | Added | Removed | Old targets | Net lines | Runtime token changes | Test token changes | Token-preserving changes |
|---|
A “token change” is a changed non-comment PHP token sequence in a file, not proof of a feature or bug fix. Old targets count removed-line coordinates within each commit; summing history repeats touches. The unchanging closing brace is not a deleted target. Binary lines are unknown, not zero.
Read the outcomes beside the activity
Whole-fixture evidence below is independent of the interactive activity filters.
Outcomes below are retained fixture execution/review observations attached to actual commit hashes. They cannot be inferred reliably from a commit message or line count. Missing evidence remains unknown.
03 / Code over time
The codebase gets smaller.
The contract stays put.
Follow ten branch commits over eleven synthetic calendar days. The chart tracks physical runtime PHP lines, including comments. It makes Carl’s comment growth and Chloe’s refactor visible without confusing size with value.
| Date / author | Commit | Added / removed | Runtime lines after | Observed work |
|---|
Author dates are synthetic and fixed for reproducibility. A Git author name/email is an assertion in a commit, not verified human identity. Ten local merge commits are listed separately from the ten author branch commits, so their diffs are not counted twice. There are no coauthor trailers.
04 / The 500-line test
Four lines are better here.
Three are wrong.
The sample shipping rule accepts integer zones 1–10 and integer weights 1–10. The price is 100 cents per zone plus 25 cents per weight. The intentionally bloated baseline spells out 99 cases and uses the last valid pair as its default. Chloe expresses the same rule directly.
Chloe’s complete four-line function
@@SHORT_CODE@@Four physical lines is a presentation choice. The meaningful improvement is 99 fewer branch tokens, less repetition and zero observed contract mismatches. This is not a claim of measured speed or reduced defects in a real product.
Try a valid input—or break the guard
Browser visualization of the PHP example. The actual PHP implementation and recorded execution are in the kit.
Zone 3, weight 4: both valid implementations return 400 cents.
Try zone 0. The actual unsafe PHP variant mismatches all 12 invalid-boundary checks. A green valid example alone would miss the defect.
Inspect the complete 500-line baseline
This deliberately repetitive teaching function is exactly 500 physical lines. It is not copied from a client system.
@@LEGACY_CODE@@| Observation | Baseline | Chloe | Unsafe shorter variant |
|---|---|---|---|
| Function physical lines | 500 | 4 | 3 |
| Branch tokens in shipping function file | 100 | 1 | 0 |
| Valid integer pairs match | 100 / 100 | 100 / 100 | 100 / 100 |
| Invalid-boundary outcomes match baseline | 12 / 12 | 12 / 12 | 0 / 12 |
All 100 valid pairs exhaust the stated finite valid domain. Twelve invalid-boundary examples exercise rejection, including PHP integer extremes. They are not a formal proof over all possible inputs, types or environments. No timing benchmark is claimed.
05 / Reproduce the evidence
Build the history.
Read the diff. Run PHP.
- Extract the resource kit.Install Python 3.10+, Git and PHP 8.2+ with ctype, date and filter using your normal approved tools. The browser page needs no PHP server, account, token, upload or database.
- Create a new synthetic repository.The generator refuses an existing workspace and creates separate seed, integration and review repositories. It performs local-only branches, simulated PR reviews, no-fast-forward merges and fast-forward pulls; it never contacts an external remote, pushes, creates a real PR or changes global Git configuration.
- Execute the known fixture.The generator compares before/after behavior and runs the unsafe short counterexample. Run each included PHP test to see actual failures rather than relying on a dashboard badge.
- Analyze the repository.The Python tool reads Git objects and lexes source using its own PHP helper. It does not include analyzed files, execute a target repository’s tests, check out revisions, run hooks or contact a network.
- Review evidence and attribution.Open the CSV/JSON, inspect full SHAs and paths, and compare outcomes. Add approved alias/coauthor/review mappings for a real study; do not silently treat commit email as a verified person or blame as effort.
Inspect Chloe’s exact diff
@@GIT_CODE@@--numstat reports three added lines and 499 removed lines. A zero-context hunk targets 499 old line positions. “Replaced lines” is not a primitive Git fact: min(added, deleted) gives only an upper bound, here 3; it does not pair semantically equivalent statements. The 500 → 4 function measurement is separate.
Analyzer boundaries
The CLI bounds retrieved history to 500 commits by default (maximum 2,000), source blobs to 1 MiB and Git output to 24 MB. The SDK fixture uses an explicit baseline..HEAD range across all reachable branches, excludes merge-commit activity and vendor paths, and reports renames as delete-plus-add. Its default first-parent mode is available for deliberately linear histories only. These explicit simplifications are suitable for the fixture, not a complete attribution solution for a branched organization. The JSON keeps those limits visible.
06 / Compare approaches
Use a matrix.
Resist a magic number.
| Approach | Useful for | Misses |
|---|---|---|
| Commits / additions / churn | Locating activity and estimating review surface | Value, difficulty, equivalence, hidden collaboration; easy to inflate |
| Targeted old lines / paths / language | Explaining the scope of edits over time | Whether a deletion improves anything; repeated historical touches |
| Whitespace / non-comment token comparison | Separating comment/reformat churn from changed tokens | Universal semantic equivalence; magic line constants and reflection are exceptions |
| Blame with move/copy or ignored-revision heuristics | Finding retained-line provenance for investigation | Deleted work, review, authorship verification, effort and business impact |
| Test, outcome and review evidence | Supporting a particular correctness or maintenance claim | Unmeasured cases, production impact and human context |
Documentation, tests and architecture can unlock work without changing a runtime token. Languages have different idioms and formatting; comparing their raw line totals as productivity rewards is not valid. This Lab deliberately offers separate lenses rather than a weighted employee leaderboard.
07 / Discuss it in an interview
Explain the change.
Show what would falsify it.
For a candidate
Choose an authorized change. Explain the old behavior, the target, the affected files/languages, the tradeoff, and your role alongside reviewers or collaborators. Show a failing-before/passing-after test and a case your change does not cover.
For a reviewer
Ask why the change was needed, what was preserved, how the evidence was gathered, and what might regress. Evaluate the actual code and reasoning. Never turn this synthetic exercise into a deletion quota or an automated hiring verdict.
Work backward from an outcome
- State the claim: same shipping behavior with less duplicated branching.
- Decide the observations that could contradict it: changed valid totals, accepted invalid inputs, or untested callers.
- Retain original code and a stable input set; run both implementations.
- Inspect the counterexample: the three-line version is shorter and fails.
- Report the measured difference and limits. Do not tune weights until your preferred person wins.
Tests and business-outcome evidence come from outside Git. The SPACE research example below likewise treats productivity as multiple dimensions, rather than a single activity count.
08 / Code + resources
Take the experiment apart.
One reproducible resource kit
Python analyzer and fixture generator, PHP lexer helper, all PHP snapshots and tests, observed JSON/CSV, expected results, readable web source and compiled CSS, setup/how-to, method notes, checksums, MIT license and a recording storyboard. The exact pinned SDK snapshot and its original MIT license are included. No .git checkout, private repository, applicant data, credentials or deployment operator is included.
Download SOURCE.zip ↓Project Lead: Chason Arthur · Code: MIT · Python 3.10+ / Git / PHP 8.2+ with ctype, date and filter · Local-only fixture · All five sample programmers use PHP.
Primary examples behind the method
- Git log documentation: author/date/path history and numstat activity.
- Git diff documentation: hunks, whitespace handling and rename heuristics.
- Git blame documentation: retained-line provenance, ignored revisions and move/copy options.
- PyDriller modified-file API: an established example exposing added/deleted lines, methods and code metrics. This kit does not require or install it.
- The SPACE of Developer Productivity: research explaining why individual activity is not a sufficient productivity measure.
Documentation checked November 5, 2026. These sources inform the approach; none endorses this synthetic fixture as a hiring or productivity instrument.
Keep the engineering connected
If a related Lab route changes, use the current Lab catalog.