YAGNI IMO

You aint going to need it = YAGNI

When I first learned about YAGNI I was learning about it while I was in the context of doing code level design.

I learned object oriented programming at the same time as structured programming. I didn't realize that I entered the field during a time of transition. Object oriented programming has what is known as polymorphism. Polymorphism allows a procedure of function to be declared with one name and have many versions taking different types and numbers of parameters. In this context of designing object oriented code and specifically polymorphic methods is where I learned and applied the "mantra" of YAGNI.

Often I would feel "pressure" to write a method with many different sets of parameters. Here is a contrived example (without much thought put into it)

public string GetName(PersonID pid){...}
public string GetName(Person person){...}
public string GetName(string personXML){...}

The reason these three methods were coded would be because the Person class has these methods:

public class Person
{
public PersonID GetPersonID(){...}
public string SerializeToXML(){...}
}

So the rationale was that you didn't know how someone might want to call your methods and it is clear that they may have a Person, a PersonID, or some XML representing a person so therefore robust code will handle all three types.

I was young and didn't know better and hadn't really thought it out.

I would write all of these polymorphic methods and then guess what, I would have to maintain all of them as well.

As I learned not to develop polymorphic methods just for the sake of someone who MIGHT want it that way I learned of YAGNI and I said, "That's it. YAGNI describes a way to avoid a maintenance problem I am experiencing in a way that I can now describe to those that are still arguing for many polymorphic methods using the term ROBUSTNESS for their defense."

So, for me ROBUSTNESS and YAGNI collided! I liked it.

Over the years I have seen YAGNI applied to other things instead of code level design. Now maybe it was originally envisioned for something other than code level design and I had applied it to the wrong problem. If I have done this, then I say it worked well for me and has been a sound approach for avoiding duplicate code!

I have seen YAGNI applied to extra features that developers want to add to a product. I have heard this called "gold plating" as well. Most developers get ideas as they work on a product. In this case the idea is that the PRODUCT aint going to need it. (Should we call this PAGNI? Which implies the customer aint going to need it. CAGNI? James CAGNI?)

The application of YAGNI to gold plating seems to hold well enough with me. But it is fairly distant from YAGNI in code level design.

More recently I have heard of YAGNI being used during release planning of a product. This is where the application of YAGNI gets fuzzy for me. If there is a list of product requirements and these requirements are being sliced up into releases then all of the requirements are needed by definition of being a requirement. (Do not jump on the BIG UPFRONT WHATEVER BAND WAGON. I am not on that wagon and it is not my point.) So using YAGNI based arguments at release planning seems really far from code level design and is very very fuzzy to me.

Release planning may have statements like "we can't do B before A" or "we can't do C,D, and E with the resources we have" or "H, I, and K are so far out we are not sure the technology won't change before we get there", stuff like that.

Here is an interesting correlation. Methods are interfaces into the code. Polymorphism may be thought of as multiple ways of doing the same thing. Correlate this to User Interface design. There may be more than one UI control that could be used for some particular interaction with the user. Is it necessary to provide the user with three different ways to enter their user name? It is natural for me to apply YAGNI at this level.

So, I use YAGNI during arguments of code level design and user interface design. In other phases of development I may be arguing what some would call YAGNI but to me it is different. I like to keep things simple. YAGNI for code level design and YAGNI for UI design.

Geoff