YAGNI: Is It True?

From AgileOpenNorthwest

Topic: "YAGNI: Is It True?" Time: February 10 2010 9:00 AM Location: Lopez C Host: Anthony Stevens

Thesis: Traditional XP suggests that YAGNI (acronym for You Ain't Gonna Need It) is a great heuristic to use when deciding whether or not to code something. But is this always true? If there are exceptions, what are they and what are the additional rules of thumb to use?

Discussion synopsis: We talked about three common violations of YAGNI:

• Adding a feature that the product owner didn't ask for
• Implementing additional engineering features or into the code, design, or architecture
• Goldplating

Of these, goldplating is a pejorative term implying that the developer is perfecting and tweaking his code for no other reason than to, well, perfect and tweak his code. Obviously bad. The first is also bad, because you're not giving the product owner the features that they asked for.

The second item is where the gray area starts to take shape. A few examples that were brought up:

• The customer requests a quick fix whose easiest solution is to hard-code the values into the compiled code. Is it better to implement a more robust, configurable, and maintainable solution even if it's not the quickest? Should the product owner be the sole decider, or does the engineering organization have a stake in the quality of the outputs as well?
• The customer never requests something like logging, and keeps de-prioritizing that story on the backlog. At some point does the engineering organization have a responsibility to push that story in the interests of lowering overall application support costs?
• Building in features for testability. This is common in the hardware world, where chips have special designs that are meant ONLY for testing. Can/should engineering organizations build similar "testability" features into their codebase to make testing easier and less costly and therefore result in a higher quality product?

One good heuristic that an attendee noted is "Would this proposed solution be embarrasing to explain to a coworker". If the answer is yes, then maybe you're doing TOO simple of a design.

Another metaphor that was discussed was the notion of a "water line". Every design decision that you make in the interest of expediency (YAGNI) raises the weight of your technical debt and pushes you further below the water line. Eventually you're so far below the water line that you drown.

Finally, the notion of "proper coding practices" was discussed, and a couple points were raised:

• Each organization has its own tolerances; what is technical debt to one group may not be to another group. Many factors go into this calculation.
• Good coding practices are like honesty - if you always tell the truth, you never need to worry later about what you said to whom. You just know that when you return to your code, it will be correct.