Weblogs Forum - YAGNI's and Planning for Change

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
YAGNI's and Planning for Change

29 replies on 2 pages. Most recent reply: Jul 19, 2005 10:13 PM by Maxim Noah Khailo

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

YAGNI's and Planning for Change (View in Weblogs)

Posted: Jul 14, 2005 11:04 AM

Reply

Summary
YAGNI stands for "You aren't going to need it", and is a fundamental anti-principle of the Agile software development philosophy. However designs which plan for change are not YAGNI's.

Advertisement

Avoiding YAGNI's is excellent advice. A YAGNI (You Aren't Going to Need it) is superfluous functionality. This principle goes hand in hand with the KISS principle (Keep It Simple Stupid). However there is another fundamental fact about writing software: almost all code will change (sorry, no clever mnemonic for that one).

With experience as a programmer it eventually becomes painfully clear that change is a a fundamental fact of code, despite our best efforts at resisting it (at least my best efforts). Almost all code gets refactored at one point or another whether you like it or not. This is in of itself a good reason to avoid YAGNI's: your code may change before you need it! Change in code is inevitable because client's needs change, software requirements change, platforms change, languages change, libraries change and of course programmers themselves change!

Some people seem to mistake designs which factor in the possibility of change as being a YAGNI, when in fact it is an anti-YAGNI. In other words, plan for change, because you are going to need it.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 11:15 AM

Reply

I'm having trouble parsing this. I think you have to let the tires hit the pavement and give an example.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 11:32 AM

Reply

> I'm having trouble parsing this. I think you have to let
> the tires hit the pavement and give an example.

:-)

Is policy based design a sufficient example? Check out http://www.informit.com/articles/article.asp?p=167842&seqNum=13&rl=1

Another example in Java are designs which make liberal use of interfaces. The idea being that whether or not you need the interface in the specific design, it is trivial to add, and makes your designs significantly easier to refactor.

I know that Michael you have extensive experience refactoring code, so I bet you probably have a whole bag full of techniques for writing refactorable friendly code. Have some of those techniques been mistaken for YAGNI's in the past? Do you think any of them could?

Would you like me to try and come up with a more concrete example?

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 12:52 PM

Reply

> > I'm having trouble parsing this. I think you have to
> let
> > the tires hit the pavement and give an example.
>
> :-)
>
> Is policy based design a sufficient example? Check out
> http://www.informit.com/articles/article.asp?p=167842&seqNu
> m=13&rl=1
>
> Another example in Java are designs which make liberal use
> of interfaces. The idea being that whether or not you need
> the interface in the specific design, it is trivial to
> add, and makes your designs significantly easier to
> refactor.
>
> I know that Michael you have extensive experience
> refactoring code, so I bet you probably have a whole bag
> full of techniques for writing refactorable friendly code.
> Have some of those techniques been mistaken for YAGNI's
> s in the past? Do you think any of them could?

Sorry if that sounded a little terse, Chris. I was posting quickly :) To me, the key thing that makes code refactorable is tests. Everything else is gravy.

The only thing I do that could really be mistaken for YAGNI-violation is to keeping classes and methods focused on single responsibilities. Some people look at code like that and think it is over-engineered because it consists of lots of small pieces, but to me it isn't, it's just well factored.

Interfaces are easy to add when you need them so I let need justify them. If I need to mock something out, it gets an interface. If something gets more than a couple of users, it gets an interface.

I think that Alexandrescu's policy based design is great, but I wouldn't adopt it wholesale as an approach for application level code. I can imagine refactoring into those sorts of solutions if the need arose, but to me, doing it from the start is too anticipatory unless you are writing a library.

One thing that I don't think we talk about enough is how there are significant differences between writing library code and writing application code.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 1:14 PM

Reply

> Sorry if that sounded a little terse, Chris. I was
> posting quickly :)

I am sorry, I didn't think you were terse and I am sorry if I came across as sounding standoffish :-)

> To me, the key thing that makes code
> refactorable is tests. Everything else is gravy.

Interesting point.

> The only thing I do that could really be mistaken for
> YAGNI-violation is to keeping classes and methods focused
> on single responsibilities. Some people look at code like
> that and think it is over-engineered because it consists
> of lots of small pieces, but to me it isn't, it's just
> well factored.

Yes I fully agree! Small functions, small classes, and small units. It is far easier to work with this kind of code, and you can often recombine the pieces in new and interesting ways. Programming like that leads to reusable code.

> Interfaces are easy to add when you need them so I let
> need justify them. If I need to mock something out, it
> gets an interface. If something gets more than a couple
> of users, it gets an interface.

I think I see, your point is refactor early and frequently, before it is too expensive? I think we fundamentally agree, its just that we differ on precisely when to do this; early, or preemptively. I am just really lazy and hate rewriting code. So I prefer to preempt the refactoring, I find that since I do it out of habit, it takes no extra development time.

> I think that Alexandrescu's policy based design is great,
> but I wouldn't adopt it wholesale as an approach for
> application level code. I can imagine refactoring into
> those sorts of solutions if the need arose, but to me,
> doing it from the start is too anticipatory unless you are
> writing a library.

Yes, the policy class design is sometimes overkill.

> One thing that I don't think we talk about enough is how
> there are significant differences between writing library
> code and writing application code.

At this point I don't agree. In my experience the code which is easiest to work with, is code which is written most like a library (but without the YAGNI's).

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 2:19 PM

Reply

> > One thing that I don't think we talk about enough is
> how
> > there are significant differences between writing
> library
> > code and writing application code.
>
> At this point I don't agree. In my experience the code
> which is easiest to work with, is code which is written
> most like a library (but without the YAGNI's).

We might still agree. I like all code to be clean, but to me application code is more like code in motion than code at rest. Classes may not have everything that any user might want, or expect to see given their names, but that is because we can add those things. As well, there may be places that point toward an obvious refactoring, a developer may have separated the fields in a class into two groups for instance, in anticipation of an extract class but until the concrete need is there, it may not be done.

In libraries, it seems like we have to finalize things much more strictly. In application code we can tolerate more ambiguity. Or, at least that's the difference I notice.

Noam Tamim

Posts: 26
Nickname: noamtm
Registered: Jun, 2005

Re: YAGNI's and Planning for Change

Posted: Jul 14, 2005 2:22 PM

Reply

[on refactoring to interfaces]
> I think I see, your point is refactor early and
> frequently, before it is too expensive? I think we
> fundamentally agree, its just that we differ on precisely
> when to do this; early, or preemptively. I am just really
> lazy and hate rewriting code. So I prefer to preempt the
> refactoring, I find that since I do it out of habit, it
> takes no extra development time.

Today's tools (mainly Eclipse) make most refactoring pretty simple. You have almost nothing to rewrite. The "introduce interface" refactoring is a good example of this: you pick methods, pick interface name - and voila, you have refactored the code.
Of course, you still have to think (design) when you do that...

- Noam
http://noamtm.blogspot.com

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 7:25 AM

Reply

It is worth recalling the underlying reason for the mnemonic YAGNI: spending effort on features that are merely predicted and not needed now is wasteful. This assumes other agile contexts hold: the kind of project has varying requirements, other agile practices make code easier to change, etc.

The questions one could ask oneself are: "Do I need this now?" and "Is it going to take any effort?" If you are being truly eXtreme you ignore the second question, and only do what you need. But you could try to balance the two. If something takes minimal effort it would probably be worth doing, even if it is fairly unlikely to be needed.

But that sort of informal programmer guestimatology seems a bit suspect. If one wants to pursue that path then a more disciplined guide ought to be derived from analysis of previous projects. That could almost be a whole process invention itself...

Specific to the original post: "designs which factor in the possibility of change" are wrong by the YAGNI rationale, since you don't need them now, and they take effort. The burden of change is supposed to be shifted onto other agile practices: keep everything simple and factored, have lots of tests, re-assess requirements and make small releases often. It is the principle of 'embracing' change rather than trying to avoid it.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 7:46 AM

Reply

> In libraries, it seems like we have to finalize things
> much more strictly. In application code we can tolerate
> more ambiguity. Or, at least that's the difference I
> notice.

Yes I agree with this point.

What I notice about library code versus application code, is that library code presumes it will be read, and reused. A lot of application code is written with an assumption that it won't be used in other unplanned contexts (which usually ends up being proven to be false). This is why I say I think application developers need to program more like library developers.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 7:55 AM

Reply

> It is worth recalling the underlying reason for the
> mnemonic YAGNI: spending effort on features that are
> merely predicted and not needed now is wasteful.

Yes thank you.

> This
> assumes other agile contexts hold: the kind of project has
> varying requirements,

I have never heard of a project which does not have varying requirements.

> other agile practices make code
> easier to change, etc.
>
> The questions one could ask oneself are: "Do I need this
> now?" and "Is it going to take any effort?" If you are
> being truly eXtreme you ignore the second question, and
> only do what you need.

Effort is relative, an inexperienced and naive programmer (say myself a few years ago) will bad choices require mroe effort. I think that relying on effort as a guide-post is somewhat of a miselading heuristic.

> But you could try to balance the
> two. If something takes minimal effort it would probably
> be worth doing, even if it is fairly unlikely to be
> needed.
>
> But that sort of informal programmer guestimatology seems
> a bit suspect.

Oh, I guess we agree then. :-)

> If one wants to pursue that path then a
> more disciplined guide ought to be derived from analysis
> of previous projects. That could almost be a whole process
> invention itself...

Worth pursuing as an idea.

> Specific to the original post: "designs which factor in
> the possibility of change" are wrong by the YAGNI
> rationale, since you don't need them now, and they take
> effort.

A flexible design does not imply superfluous functionality. Also, as I said earlier effort is relative. My coding style has evolved over the years to the point to incorporate anticipation of change with relatively little effort.

> The burden of change is supposed to be shifted
> onto other agile practices: keep everything simple and
> factored, have lots of tests, re-assess requirements and
> make small releases often. It is the principle of
> 'embracing' change rather than trying to avoid it.

Nonetheless my point is that while change is inevitable, we can minimize the amount of work it will imply through flexible designs.

The rule that an ounce of prevention is worth a pound of cure, I think is completely relevant to programming whether or not you are using XP practices.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 8:02 AM

Reply

I just want to follow this up with a more concrete-example: a program written using one thousand line function.

According to a naive application of the YAGNI principle, this is fine. It could be argued it is easier to write code without other functions. Is this is a good idea? Well the code is harder to read, harder to maintain, harder to refactor. Furthermore refactoring is practically guaranteed.

Ever try to refactor code like that? You have to write entirely new test cases, etc. etc. It is long and slow. This doesn't counter YAGNI, it just demonstrates that what you are going to need and what you aren't going to need, is two different things.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 8:12 AM

Reply

> I just want to follow this up with a more
> concrete-example: a program written using one thousand
> line function.
>
> According to a naive application of the YAGNI principle,
> this is fine. It could be argued it is easier to write
> code without other functions. Is this is a good idea? Well
> the code is harder to read, harder to maintain, harder to
> refactor. Furthermore refactoring is practically
> guaranteed.
>
> Ever try to refactor code like that? You have to write
> entirely new test cases, etc. etc. It is long and slow.
> This doesn't counter YAGNI, it just demonstrates that what
> you are going to need and what you aren't
> going to need, is two different things.

Yes, and people who quote YAGNI don't use it as it if was the only design principle, really. Another thing that helps is Beck's rules of simple design:

In priority order, the code must: 1. Run all the tests 2. Contain no duplicate code 3. Express all the ideas the author wants to express, and 4. Minimize the number of classes and methods.

The priority ordering is important. You may have a simpler design that has more classes than a less simple design, provided you needed them to express the ideas you needed to. In conjunction with YAGNI, this gets close to the core of what emergent design is.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 8:45 AM

Reply

Near the beginning of 'XP Explained' is given one of the premises of XP: that the cost of change doesn't increase with time. This, assuming one uses/believes XP, invalidates the 'ounce (gram) of prevention is worth a pound (kilogram) of cure' saying.

With that premise, the proposition of starting with flexible designs becomes weakened. They take more work than simpler designs, and are founded on risky predictions. It is cheaper to delay work on more complex designs, because they can then be based on the certainty of immediate requirements. The risk of up-front design work equates to extra cost, in aggregate and comparatively to agile re-design.

The belief that one has evolved coding style to "incorporate anticipation of change with relatively little effort" has inchoate appeal (and must surely be partly true). But, as I suggested, advocacy of this needs more than a 'guestimatology' to argue strongly against XP.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 8:54 AM

Reply

> Near the beginning of 'XP Explained' is given one of the
> premises of XP: that the cost of change doesn't
> increase with time. This, assuming one uses/believes
> XP, invalidates the 'ounce (gram) of prevention is worth a
> pound (kilogram) of cure' saying.
>
> With that premise, the proposition of starting with
> flexible designs becomes weakened. They take more work
> than simpler designs, and are founded on risky
> predictions.

I think the key insight is that simplicity is flexibility, really. When you squeeze out duplication, have tests for everything, and name things well, code can accomodate change more easily.

Re the cost of change, yes, it makes sense to watch out for that. When I'm tempted to do something anticipatory, I ask myself whether it would cost significantly more to add later, if it does, it makes sense to think about adding it now. If it doesn't, I'm better off waiting to see if I really need it.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 9:01 AM

Reply

> Re the cost of change, yes, it makes sense to watch out
> for that. When I'm tempted to do something anticipatory,
> I ask myself whether it would cost significantly more to
> add later, if it does, it makes sense to think about
> adding it now. If it doesn't, I'm better off waiting to
> see if I really need it.

I am fully on the same page with you here. I think it is worthwhile incorporating this insight into the XP/Agile guiding principles.

Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use