# JDD-Description: a Korean satire manifesto for the developer who has already rehearsed the excuse

> A documentation-only repository that invents a fake development methodology built entirely on plausible-sounding justifications, written in Korean and packed with real workplace observations.

**Lee-WonJun/JDD-Description** — Ju-Dung-A-Li Driven Development

- Repository: https://github.com/Lee-WonJun/JDD-Description
- Stars: 2,141 · Forks: 141
- Language: Unknown
- License: not declared
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/lee-wonjun-jdd-description

## A repository with no code, no license, and a manifesto in its place

The repository tree is the whole story: a `README.md`, a `.github/` directory, and a `.agents/` directory. There is no source directory, no package manifest, no build configuration and no test suite. The GitHub topics field carries a single tag, `manifesto`, which is a more honest description than most project topics.

The metadata is similarly minimal. There is no license, so the code has no license to inspect, and no primary language is detected because nothing here is a programming language in the sense GitHub measures. The description field is the six-word expansion of the acronym: Ju-Dung-A-Li Driven Development. The `main` branch carried its last push on 2026-07-08.

What it does have is a following. 2,140 stars and 142 forks with zero open issues, which is the profile of something people read and share rather than something people file tickets against. The two releases both landed on 2026-04-01: version 1.0.0, whose changelog is a list of typo fixes and README updates contributed by about a dozen different people, and a second tag named `1.0.1-April-Fool's-UPDATE` with nothing but a compare link. That second tag is the clearest signal about what kind of artifact this is.

## Four founding values, and the sentence that explains the mechanism

The README opens by defining JDD as a development methodology you practise by thinking harder about your excuses in advance rather than by writing code, on the theory that this reliably produces bugs. It then states four values the method holds to, in a block that sets up a left side and a right side with an explanation underneath. My own technology over everyone else's. Tricky code over clean code. Excuses over bug fixes. Convenience over effort.

The closing sentence is the actual thesis of the repository, and it is worth reading as design rather than as a joke. It explains that the items on the left are the inconvenient ones and the items on the right are the convenient ones, and the method simply assigns higher value to the right. That is a coherent position. It is also obviously wrong as engineering advice, which is what makes it a good vehicle.

Each subsequent section is a specialised version of the same move. The section on defensive programming tells you to defend the work item rather than the code. The section on performance tells you that slow software means your machine is bad. The section on modern programming tells you to use whatever you currently use, because that is what modern means. The repetition is the joke and the technique at the same time: by the twentieth variation the reader has internalised the structure and can fill in the rest.

## The fixed phrase that turns an excuse into a reusable script

Every bullet in the README follows one of two templates. The first is a bare instruction. The second is an instruction followed by a scripted reply to whoever objects, and that reply always invokes a named methodology. Never write comments, because if someone says the code should be readable, cite clean code. Do not maintain anything, because if someone asks about long term upkeep, say MVP. Do not review code, because your code is unconditionally correct.

The pattern makes the repository unusually quotable. Each bullet is self-contained, translatable into any language in about twenty words, and funny in isolation, which is exactly what a chat message needs to be. The contributor pull requests visible in the 1.0.0 changelog are mostly typo corrections and categorisation work, which suggests the community treated it as a living document and not as a finished joke.

The satire also has a real target. Almost every entry in the codebase, documentation, collaboration, testing and design sections describes something a working developer has genuinely been tempted by, usually because the temptation was reasonable in the moment. The testing section is the sharpest example, since its advice ranges from skipping tests on the grounds that a REPL is enough, to deleting a test when it fails. Read as a description of how teams talk, this repository is closer to ethnography than to parody.

## A documentation section that quietly absorbed the current model era

The section on documentation is the one that shows the repository being maintained rather than performed. Its advice is to never write comments, never write documentation on any grounds, keep no history, write no handover documents, and leave quickly without sentiment. Each of those ships with its own scripted defence.

Then the register changes. Instead of inventing a name for the shortcut, the section makes an actual argument: model progress is extremely fast, so if someone claims documentation is necessary, say the model will produce it for you. The next bullet goes further and suggests actively using ChatGPT, generating the documentation by asking it, and answering objections by saying the model is more accurate. A repository written as satire against documentation duty quietly acquired a documentation duty itself.

The collaboration section closes on a one-line bullet about what a colleague said, which is the only place in the file where a named tool appears outside a parenthetical gloss. That is the joke landing in the driest possible spot, right after a long list of instructions about squash merges, force pushes and never sharing a colleague's typos. The last line of the performance section is truncated in the source, which is a small piece of evidence about how the file is edited, by adding bullets and adjusting later.

## What the jokes are actually about, section by section

The outline follows the arc of a career in about fifteen headings, and the ordering matters. Foundations comes first: what qualifies you as a real leader, and how to defend your own incoming tasks. Then performance avoidance, covering concurrency, documentation and collaboration. Then the part where everything is programming, divided into modern programming, language, design, testing and performance optimisation. Reading those headings in sequence gives you a trajectory from an inexperienced developer to a senior one, and the satire sharpens with each step because the excuses get more polished.

The modern programming section is the longest at 48 lines and the most purely mechanical. Its method is to reach for whichever jargon name applies to whatever you already did: if there is chaining it is a fluent API style, if there is none it is the law of demeter, if functions only call functions it is a DSL, if there are annotations it is metaprogramming. It includes the two-sided rule that code longer than yours is verbose and code shorter than yours is esoteric, and the two-sided rule that design below yours is technical debt while design above yours is over-engineering. Those two are the most quotable lines in the repository, and they are the clearest demonstration of the method: the judgement is always defined so that your own work is correct by construction.

The language subsection is only three entries long and leans entirely on one scriptable sentence, which reads roughly that in any language argument you win by declaring that a language is a tool. The two follow-up entries extend it: supersets of JavaScript are rejected on the grounds that the language was designed that way and therefore that is the essence, and languages you have no personal grievance about are handled by citing somebody else's complaint site instead of forming your own.

```
- 언어논쟁에서는 선빵 필승의 문장이 있다 "언어는 도구다".

- TypeScript, CoffeeScript, ClojureScript 등 JS 의 슈퍼셋은 일절 사용하지 않는다. 누가 뭐라고 하면 JS는 애초에 그렇게 설계된 언어이고 그것이 곧 근본이라 하자.

- 몇몇 언어는 굳이 내가 불평할 필요가 없다. wtfjs / golang.sucks 등 다른 사람의 불평을 인용하자.
```

The design section carries the sharpest single line, which argues that null is worth ten billion won and that whenever a return value is ambiguous you should return null, refined to returning null from a function typed as Object or Any. The concurrency section, at nine lines, is the shortest and depends most on the reader recognising a real argument, since its case rests on comparing the discomfort of occasional bugs to the convenience of mutable variables in multithreaded code. That is a trade-off real engineers genuinely argue about, which is why it works.

## Why this earns forks, and what a reader gets out of it

The engagement pattern explains the popularity. A repository like this is not cloned or depended on, so forks carry no technical weight here; they are people keeping a copy to send to a colleague, which is what 142 forks means for a document. The star count is closer to applause than to intent to use, and the near-zero issue count says people arrive, read, and leave.

For a reader who does not read Korean, the barrier is real, and it is the main practical limitation. There is no English version, no translation issue, and no second README. What survives translation is the structure, which is why the pattern matters more than the vocabulary: a list of stated bad habits paired with the sentence you say when someone catches you doing them. That structure works in any language and in any team.

There is also an audience question worth settling. The named target is the developer who has already prepared their justification, and the tone is affectionate rather than contemptuous, which is why the contributions are corrections rather than takedowns. The final line of the value block, the one about the left being inconvenient and the right being convenient, is the closest thing to an actual argument in the file, and it is the one a reader is most likely to disagree with. That is the intended response, and it is also what makes the piece worth reading as a description of how engineering work gets justified in practice.

## Conclusion

JDD-Description works because it is not a joke about stupidity. Every entry describes a defensible-sounding shortcut that a competent engineer has genuinely considered, usually with a real reason attached, and then attaches a name to it so the shortcut can be repeated without the justification. The repeated phrase roughly meaning if anyone objects, say this, is the load-bearing device: it converts an excuse into a script, and a script can be shared. That makes the repository closer to a piece of workplace folklore than a piece of satire, which is also why it earned 2,140 stars and 142 forks with no code and no license. Read it as a catalogue rather than a guideline. The section on documentation has been quietly updated for the model era, replacing an earlier certainty with a claim that the model will write the docs for you, which tells you the repository is being tended by people who are tracking what their teams actually say. The prose is entirely Korean, which limits who can read it directly and rules out a straight translation. Start with the four founding values near the top, because every later section is an elaboration of one of them.

## FAQ

### What is JDD-Description?

It is a documentation-only GitHub repository presenting a fictional development methodology called Ju-Dung-A-Li Driven Development, written entirely in Korean as a satire of justifications developers use to avoid work.

### Is there any code in this repository?

No. The tree contains a README, a .github directory and a .agents directory, and there is no source code, no build configuration and no test suite. The GitHub topics field lists a single tag, manifesto.

### Is the repository licensed?

No license file is recorded in the repository metadata. The README text is a satirical document, but there is no explicit permission grant attached to it.

### What language is the README written in?

Korean, throughout, with English technical terms kept in parentheses so that jargon such as trunk-based development or property based testing survives the translation. There is no English version of the document.

### Why does the repository have releases?

Both were published on 2026-04-01. Version 1.0.0 lists typo fixes and README updates from about a dozen contributors, and the follow-up tag is named 1.0.1-April-Fool's-UPDATE and contains nothing but a compare link.

### Who is the satire aimed at?

At developers who have already prepared a justification for skipping a task. Every entry pairs a stated bad habit with a scripted reply for whoever objects, which makes the document a set of reusable excuses rather than advice.

## Sources

- [Issues](https://github.com/Lee-WonJun/JDD-Description/issues)
- [Lee-WonJun/JDD-Description on GitHub](https://github.com/Lee-WonJun/JDD-Description)
- [README](https://github.com/Lee-WonJun/JDD-Description/blob/main/README.md)
- [Releases](https://github.com/Lee-WonJun/JDD-Description/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lee-wonjun-jdd-description