You ain't gonna need it
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) m |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
==The benefits== | ==The benefits== | ||
| − | * Chasing | + | * Chasing fewer bugs. Nothing is more of a pain than chasing bugs through code that isn't even executing - lots of dead ends! |
* It keeps the [[cognitive load]] down when looking at strange code. It self-documents because, by it's very existence, it honestly declares what the software actually does | * It keeps the [[cognitive load]] down when looking at strange code. It self-documents because, by it's very existence, it honestly declares what the software actually does | ||
| − | * Dead code is not part of the integration-testing loop, so in a test-driven process, it's not valid code. It also tends to fall behind requirements. | + | * Dead code is not part of the integration-testing loop, so in a [[Test Driven Development|test-driven process]], it's not valid code. It also tends to fall behind requirements. |
| − | "The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code."[http:// | + | "The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code."[http://xprogramming.com/practices/pracnotneed.htm [xp]] |
==Conflicts== | ==Conflicts== | ||
*[[Big design up front]] | *[[Big design up front]] | ||
Latest revision as of 05:41, 14 October 2009
You ain't gonna need it, or short YAGNI, suggests to programmers that they should not add functionality until it's necessary.
Ron Jeffries, one of the 3 founders of Extreme Programming Software Development Methodology, states: "Always implement things when you actually need them, never when you just foresee that you need them." According to him you often will hear yourself saying: "We are going to need..." Just resist that impulse and stick to the essential functionality.
The benefits
- Chasing fewer bugs. Nothing is more of a pain than chasing bugs through code that isn't even executing - lots of dead ends!
- It keeps the cognitive load down when looking at strange code. It self-documents because, by it's very existence, it honestly declares what the software actually does
- Dead code is not part of the integration-testing loop, so in a test-driven process, it's not valid code. It also tends to fall behind requirements.
"The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code."[xp]
