{"kind":"Skill","metadata":{"namespace":"community","name":"thinking-lindy-effect","version":"0.1.0"},"spec":{"description":"For non-perishable things, future life expectancy is proportional to current age. Use for technology selection, evaluating frameworks/libraries, and predicting tool longevity.","files":{"SKILL.md":"---\nname: thinking-lindy-effect\ndescription: For non-perishable things, future life expectancy is proportional to current age. Use for technology selection, evaluating frameworks/libraries, and predicting tool longevity.\n---\n\n# The Lindy Effect\n\n## Overview\n\nThe Lindy Effect, named after a New York deli where comedians discussed career longevity, states that for non-perishable things (ideas, technologies, books, practices), future life expectancy is proportional to current age. If a technology has survived 20 years, it's likely to survive another 20. If it's survived 2 years, expect another 2.\n\n**Core Principle:** Time is the ultimate test. Old things that still exist have proven their value; new things are still being tested.\n\n## When to Use\n\n- Technology selection (languages, frameworks, databases)\n- Evaluating libraries and dependencies\n- Predicting tool longevity\n- Career skill investment\n- Methodology and practice adoption\n- Architectural patterns\n- Vendor/product selection\n\nDecision flow:\n\n```\nChoosing between options?\n  → Are some options significantly older? → yes → APPLY LINDY HEURISTIC\n  → Is longevity important for this choice? → yes → FAVOR OLDER, PROVEN OPTIONS\n  → Is the new thing solving a new problem? → yes → NEW MIGHT BE APPROPRIATE\n```\n\n## Understanding Lindy\n\n### What Lindy Applies To (Non-Perishable)\n\n- **Technologies:** Languages, databases, protocols\n- **Ideas:** Mathematical concepts, design patterns, algorithms\n- **Practices:** Testing, version control, code review\n- **Books:** Technical references, foundational texts\n- **Institutions:** Standards bodies, open source foundations\n\n### What Lindy Doesn't Apply To (Perishable)\n\n- **Hardware:** Physical degradation limits life\n- **Individual careers:** Humans have biological limits\n- **Specific products:** Companies can fail, be acquired\n- **Fashion-driven choices:** Popularity cycles aren't Lindy\n\n### The Math\n\n```\nExpected remaining life ≈ Current age\n\nIf survived 10 years → Expected to survive another ~10\nIf survived 50 years → Expected to survive another ~50\nIf survived 2 years → Expected to survive another ~2\n```\n\n## Applying Lindy to Technology\n\n### Programming Languages\n\n| Language | Age | Lindy Expectation | Evidence |\n|----------|-----|-------------------|----------|\n| C | 50+ years | 50+ more years | Powers OS, embedded, will outlive us |\n| Java | 30 years | 30+ more years | Enterprise backbone, not going away |\n| Python | 30 years | 30+ more years | Scientific computing, ML, scripting |\n| Go | 15 years | 15+ more years | Proven for infra, backed by Google |\n| Rust | 10 years | 10+ more years | Growing, solving real problems |\n| New hotness | 2 years | 2-5 years | Unproven, might disappear |\n\n### Databases\n\n| Database | Age | Lindy Expectation | Notes |\n|----------|-----|-------------------|-------|\n| PostgreSQL | 35+ years | 35+ more years | SQL is 50+ years old |\n| MySQL | 30 years | 30+ more years | LAMP stack foundation |\n| MongoDB | 15 years | 15+ more years | Survived NoSQL hype cycle |\n| CockroachDB | 10 years | 10+ more years | NewSQL, still proving itself |\n| Latest DB | 2 years | Unknown | High risk for production use |\n\n### Frameworks\n\n| Framework | Age | Lindy Expectation | Notes |\n|-----------|-----|-------------------|-------|\n| React | 10+ years | 10+ more years | Dominant, ecosystem mature |\n| Rails | 20 years | 20+ more years | Productive, battle-tested |\n| Django | 18 years | 18+ more years | Python's Rails, stable |\n| Express | 14 years | 14+ more years | Node.js standard |\n| Newest framework | 1 year | 1-3 years | Likely to be replaced |\n\n### Patterns and Practices\n\n| Practice | Age | Lindy Expectation |\n|----------|-----|-------------------|\n| Version control | 50+ years | Permanent |\n| Automated testing | 40+ years | Permanent |\n| Code review | 40+ years | Permanent |\n| Agile (core ideas) | 30+ years | Very long |\n| CI/CD | 20+ years | Very long |\n| Microservices | 10 years | Moderate |\n| Latest methodology | 2 years | Unknown |\n\n## The Lindy Decision Process\n\n### Step 1: Assess Age of Options\n\nFor each option, determine how long it's been in significant use:\n\n```markdown\nOptions for message queue:\n- RabbitMQ: 17 years (2007)\n- Kafka: 13 years (2011)\n- NATS: 11 years (2013)\n- NewQueue: 2 years (2022)\n```\n\n### Step 2: Apply Lindy Heuristic\n\n```markdown\nLindy expectation:\n- RabbitMQ: 17+ more years\n- Kafka: 13+ more years\n- NATS: 11+ more years\n- NewQueue: 2-5 more years (high uncertainty)\n```\n\n### Step 3: Consider Context\n\nLindy is a heuristic, not a law. Consider:\n\n```markdown\nWhen older is better:\n- Long-term production systems\n- Core infrastructure\n- Skills investment\n- Dependencies with many consumers\n\nWhen newer might be appropriate:\n- Solving genuinely new problems\n- Performance-critical new workloads\n- Specific capability older tools lack\n- Temporary/experimental projects\n```\n\n### Step 4: Calibrate by Ecosystem Age\n\nA 5-year-old tool in a 5-year-old ecosystem is \"old\" for that ecosystem:\n\n```markdown\nKubernetes ecosystem: ~10 years old\n- Helm: 8 years → \"Lindy\" for K8s\n- ArgoCD: 7 years → \"Lindy\" for K8s\n- New tool: 1 year → Not Lindy yet\n\nNode.js ecosystem: 14 years old\n- Express: 14 years → Maximally Lindy for Node\n- Fastify: 8 years → Moderately Lindy\n- New framework: 1 year → Unproven\n```\n\n## Lindy Failure Modes\n\n### Survivor Bias Confusion\n\nLindy predicts future survival given current survival. It doesn't say all old things are good:\n\n```\nCorrect: \"COBOL has survived 60 years, will survive 60 more\"\nIncorrect: \"COBOL is the best choice for new projects\"\n(Survival ≠ Optimal for new use cases)\n```\n\n### Ignoring Paradigm Shifts\n\nLindy works within stable paradigms. Paradigm shifts create discontinuities:\n\n```\n- Pre-cloud: On-premise databases were Lindy\n- Post-cloud: Managed databases emerged\n- But: Core database concepts (SQL, ACID) remained Lindy\n```\n\n### Confusing Perishable and Non-Perishable\n\n```\nPerishable: Specific SaaS vendor → Can be acquired, pivoted, shut down\nNon-perishable: The practice the vendor enables → Likely Lindy\n\nE.g., Heroku might change, but \"platform-as-a-service\" concept is Lindy\n```\n\n## Lindy in Practice\n\n### Technology Selection\n\n```markdown\n## Lindy Analysis: Database for New Product\n\nRequirements: ACID transactions, relational data, long-term stability\n\nOptions:\n| Option | Age | Lindy Score | Fit for Requirements |\n|--------|-----|-------------|---------------------|\n| PostgreSQL | 35 years | Excellent | Excellent |\n| MySQL | 30 years | Excellent | Good |\n| CockroachDB | 10 years | Good | Excellent |\n| PlanetScale | 5 years | Moderate | Good |\n\nDecision: PostgreSQL (Lindy + excellent fit)\n         Consider CockroachDB for scale needs (worth the Lindy tax)\n```\n\n### Skill Investment\n\n```markdown\n## Lindy Career Analysis\n\nWhich skills to invest in?\n\nLindy skills (high confidence in future value):\n- SQL (50+ years)\n- Unix/Linux (50+ years)\n- Git/version control (40+ years)\n- Testing fundamentals (40+ years)\n\nModerate Lindy (good bet):\n- Python (30+ years)\n- JavaScript (28 years)\n- Docker/containers (12 years)\n- Kubernetes (10 years)\n\nLow Lindy (speculative):\n- Latest framework (1-3 years)\n- Trending language (variable)\n\nInvestment strategy: Core in Lindy skills, experiments in new\n```\n\n### Dependency Selection\n\n```markdown\n## Lindy Dependency Audit\n\nFor each critical dependency:\n| Dependency | Age | Last Update | Contributors | Lindy Risk |\n|------------|-----|-------------|--------------|------------|\n| lodash | 12 years | Active | Many | Low |\n| express | 14 years | Active | Many | Low |\n| new-lib | 1 year | Active | 3 | High |\n\nPolicy: Critical path requires 5+ year Lindy\n        Experimental features can use newer dependencies\n```\n\n## Lindy Template\n\n```markdown\n# Lindy Analysis: [Decision]\n\n## Options with Age\n| Option | First Stable | Age | Category |\n|--------|--------------|-----|----------|\n| | | | Proven/Moderate/New |\n\n## Lindy Expectations\n| Option | Expected Longevity | Confidence |\n|--------|-------------------|------------|\n| | | High/Medium/Low |\n\n## Context Adjustments\n- Is this a new problem domain? [Yes/No]\n- Is the ecosystem mature? [Yes/No]\n- Do newer options solve critical gaps? [Yes/No]\n\n## Lindy-Adjusted Decision\nPrimary choice: [Option with best Lindy + fit]\nRationale: [Why this balances Lindy with requirements]\n\n## Risk if Lindy is Wrong\n[What happens if the non-Lindy option outlasts expectations?]\n```\n\n## Verification Checklist\n\n- [ ] Identified age of all options\n- [ ] Applied Lindy heuristic to estimate longevity\n- [ ] Distinguished perishable from non-perishable\n- [ ] Considered paradigm shift possibilities\n- [ ] Checked if newer options solve genuinely new problems\n- [ ] Balanced Lindy with specific requirements\n- [ ] Documented reasoning\n\n## Key Questions\n\n- \"How long has this technology/practice existed?\"\n- \"Is this Lindy (non-perishable) or perishable?\"\n- \"What's the Lindy expectation for each option?\"\n- \"Is the newer option solving a problem that didn't exist before?\"\n- \"Am I betting against Lindy? If so, why?\"\n- \"What's proven vs. what's hyped?\"\n\n## Taleb's Wisdom\n\n\"If a book has been in print for forty years, I can expect it to be in print for another forty years. But, and that is the main difference, if it survives another decade, then it will be expected to be in print another fifty years.\"\n\n\"Technology is at its best when it is invisible.\"\n\nThe technologies you don't think about—TCP/IP, Unix, SQL—are the most Lindy. The technologies that demand constant attention are still being tested.\n\n\"The old is to be respected; the new is to be examined.\"\n\nLindy doesn't mean reject the new. It means: the burden of proof is on the new. New must demonstrate value; old has already demonstrated survival.\n"},"import":{"commit_sha":"a31e22d4445ad8fef7cd771d32af537aebb68c49","imported_at":"2026-05-22T21:14:39Z","license_text":"MIT License\n\nCopyright (c) 2025 TJ Boudreaux\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","owner":"tjboudreaux","repo":"tjboudreaux/cc-thinking-skills","source_url":"https://github.com/tjboudreaux/cc-thinking-skills/tree/a31e22d4445ad8fef7cd771d32af537aebb68c49/skills/thinking-lindy-effect"}},"content_hash":[156,249,141,122,209,241,201,31,92,205,64,233,44,83,218,67,39,34,117,144,243,119,144,115,219,144,92,231,69,223,67,194],"trust_level":"unsigned","yanked":false}