Wednesday, July 26, 2006

YANGTNI

In the philosophy of agile programming there is this principle called "you are not going to need it" or YANGTNI.  The notion here is that you shouldn't add design or logic to your application in anticipation of possible future requirements.  This is a principle that resonates with me quite strongly because I have a tendency to complicate the design in anticipation of possible things to come.  An associated notion is that when the requirements change, one can refactor the code to accommodate the new or altered requirement.  The problem that I have with this concept is that it tends to be articulated in a binary or absolute matter: either you need it or you don't.

In my world, things are never so black or white.  Let's give an example.  Suppose that I'm building an application that involves pricing of product that is sold to clients.  Suppose I have a requirement that stated something like this:

The price for a quantity of product on a single order is determined using the following table:
Quantity Range     Price per unit within the range
1 thru 99 inclusive     100% of base price
100 thru 999 inclusive     80% of base price
1000 and above     60% of base price

In other words, the more units that you order at a given time, the cheaper each of those units become.  Given this requirement, I would probably add a method “ComputeTotalPrice” to a product class (with the quantity as a parameter) to perform this computation.  Now let's complicate the situation a bit.  Suppose that we have a potential client coming down the road and the negotiations with this client so far would suggest that they want to change the way that we create that table, a special arrangement just for them.  We might get a decision tomorrow or next week or at the very least by the end of the decade.

As I understand it, The YANGTNI approach would suggest that you would do nothing about this potential change, until there is a firm hard requirement upon which to base an implementation.  When you have that revised requirement, you can refactor and address the requirement.

As I said this principle resonates with me but other parts of me say, wait a minute, there's got to be more to the story.  Taking things to an extreme, that would suggest that I don't need to lock my car or my house except on the day that someone's going to break in and steal something.  I do not have to wear my seat belts when I drive except on the day that I have an accident.  The reality is that I really need sit down and do some analysis.  I need to ask:
  • What is the likelihood that this particular change is going to happen?

  • When it does happen, what is the impact going to be on the design and implementation that I currently have in place?

  • Is there something that I could do today that would reduce the potential future impact?

  • What is the cost of making that change today?

  • What is the trade-off of making the change today versus waiting until some future time?

Let me take my example a little further.  If I only compute the price by calling the method described above in one location in my code, the answer to my “what is the impact when the requirement changes” question is, "not too much".  At this point the smartest thing to do is to discontinue my analysis.  When the change happens, we can respond to it easily and quickly.  Suppose, on the other hand, that my current implantation calls this computational method in hundreds of different locations in my code.  If I know that the logic of this method and in particular the parameters that it will require are stable, this is not a bad thing to do.  The unfortunate outcome of taking this approach is that the impact of a change in the price computation that involves additional parameters, be they the identity of the customer, the region of the country, or the phase of the moon, is increased dramatically.

It just seems to me that you have to think about these things.  I think that you have to ask the question, what existing requirements have a potential for change and is there something that I could do in terms of the structure of my design that would not require a lot of effort but would position the design and implementation to more readily accommodate such changes.  

I'll come back in future postings to ways that I think you could structure your design to accommodate such potential changes.          

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home