About YAGNI & TDD

You're not going to need it, and you should build the features & functionality you need by.

Kalle Tolonen
April 6, 2024

What's TDD about [1]

1. List test scenarios you want to cover
2. Make one item on the list into a runnable test
3. Make code to so that the test (& all previous tests) pass (adding items to the list as you discover them)
4. Refactor to improve the implementation design

Rinse & repeat

Rules of TDD [1]

1. Thou shall not write any production code, unless required by a failing unit test.
2. Thou shall not write more of a unit test, than is required to fail (assertion failure/program crash/compile error).
3. Thou shall not write more production code, than is sufficient to make the one failing unit test pass.

Bullet points

1. TDD's tests provide a feedback mechanism: if something is hard to test, it means the code's design needs improvement [1]
2. You aren't going to need it is a good principle - don't build stuff nobody asked for [2]. Another way to describe this would be Elon Musk's engineering principles #1 (Make the requirements less dumb) and #2 (Best part is no part).
3. YAGNI failures are outweighted by their massive successes [2], so it's always safe to bet on less-is-more than the other when in doubt

Designing simple stuff

Simple stuff is quite hard to do. Every feature should pass tests, minimize duplication (Don't repeat yourself) & reduce complexity. TTD covers the first part well, so you should live by: DRY & great naming (methods & variables should tell what they're supposed to do). [2]

Source(s)

1

2