The lineage
Measuring software work.
Software sizing, planning estimates and delivery frameworks answer different questions. This selected history asks where TIER fits.
Measures of work make incomplete judgments of a person. TIER inherits that risk. It asks how much merged work the team's recorded AI spend bought.
Lines of code
Barry Boehm's Software Engineering Economics (1981) introduced COCOMO, estimating effort and cost from expected code size. But rewarding lines added as “output” gives deletion and reuse the wrong sign: removing code can improve a system.
“we should not regard them as 'lines produced' but as 'lines spent'”Edsger Dijkstra, On the cruelty of really teaching computing science, EWD1036, 1988
In Andy Hertzfeld's retrospective, −2000 Lines of Code (Folklore.org), Lisa programmers reported weekly code counts in 1982. Bill Atkinson's QuickDraw region rewrite removed around 2,000 lines. He entered −2000; managers stopped requesting his form after a couple more weeks.
Incentive risk — rewarding added lines rewards volumeFunction points
Allan Albrecht at IBM proposed sizing software by the functions a user receives, independently of programming language. The International Function Point Users Group's Counting Practices Manual describes counting inputs, outputs, queries, internal files and external interfaces.
Product size still leaves individual credit for shared work unresolved.
Limit — product size does not allocate individual creditStory points & velocity
Story points estimate the relative size of work. Velocity is the points a team completes in an iteration. Martin Fowler's StoryPoint and XpVelocity explain forecasting from a team's experience on its own estimation scale.
Target completed points and larger estimates can raise the number without more useful work. TIER's size labels face the same incentive risk.
Incentive risk — optimizing estimates instead of the workDORA · SPACE · DX Core 4
DORA (DevOps Research and Assessment) examines delivery systems. Forsgren, Humble and Kim's Accelerate (2018) describes the original four measures: deployment frequency, change lead time, change failure rate and time to restore service.
Forsgren, Storey and coauthors' The SPACE of Developer Productivity (2021) argues for multiple dimensions, from satisfaction to flow. Tacho and Noda's Introducing the DX Core 4 (2024) brings together speed, effectiveness, quality and impact.
TIER complements all three; the dimension-by-dimension comparison explains its narrower scope.
Design lesson — keep the other dimensions in viewGoodhart & Campbell
Marilyn Strathern states Goodhart's warning in ‘Improving ratings’: audit in the British University system (1997):
“When a measure becomes a target, it ceases to be a good measure.”Goodhart's Law · Strathern, 1997
Donald T. Campbell's Assessing the Impact of Planned Social Change (1976) warns that high-stakes decisions pressure indicators and distort the activity they describe. Team targets create that pressure too; aggregation alone cannot prevent gaming.
TIER — the yield of AI spend
TIER = summed weighted outcome points ÷ (recorded list-price AI cost / $1,000). Team scores use summed inputs. Points size work without assigning it a dollar value.
On the normal GitHub path, an outcome is a merged pull request referencing its tracker issue number in the branch name or description. A PR label or an estimate from changed code supplies size; automated build and test failures and reverts discount points. These are penalty signals rather than assessments of code quality or business impact. Recorded list-price cost includes spend within the selected repository, group and period that has no issue reference or matched outcome.
Operators choose team or division reporting for real data. These reports omit names and use k-anonymity to combine small groups or withhold results for viewer token holders. Per-developer views and the per-issue report are not available on real data in v0.6.1 (#826). The synthetic demo (tierd demo), which generates its own invented data in a private temporary database and cannot load yours, shows these views read-only with capture and write routes absent.
v0.6.1 has an admin token for reads, writes, exports, erasure and provider proxies, a read-only viewer token, a scrape-only metrics token, and an ingest token accepted only on POST /api/v1/events. Use the ingest token for laptop shippers; it grants no reads, outcomes, exports, erasure or proxy access. It is not bound to a developer identity: its holder can post usage under another name or pad a contributor group. Admin token holders can read every developer’s identifying records in any reporting mode and post or erase records. k-anonymity limits what viewers of team and division reports see; it does not restrict admin token holders. Treat admin and metrics credentials as operator-only. Without a configured admin token, the server is loopback-only and unauthenticated; other tokens alone do not enable authentication. Operators must control access and set a written policy; TIER cannot enforce the appraisal prohibition below. The operator guide covers capture, scoring and reporting setup.
The honest read
A cost lens still carries these risks.
Deletions earn points, but generated churn, inflated labels and splitting work can still raise the score. Mentoring and other work outside recorded outcomes earn no points. The 28-scenario risk assessment documents these weaknesses and hidden AI usage.
Compare the same team over settled periods with consistent labeling and prices. Cost capture and merges run on different clocks, distorting recent windows. Missing cost inflates the ratio; zero recorded cost yields no usable reading. Interpreting the number explains these limits. Try one practice change, then compare again.
Where TIER stands
TIER grades the work, not the worker. Coach the practice: examine how the team uses AI. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual.
Product descriptions follow tag v0.6.1; linked docs may advance with later releases.