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

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 9:07 AM

> Near the beginning of 'XP Explained' is given one of the
> premises of XP: that the cost of change doesn't
> increase with time.

That is true, but you can't ignore the fact that the cost of change increases with complexity and size. Usually over time complexity and size grows, so though the statement is true in theory, in practice it often isn't,

> This, assuming one uses/believes
> XP, invalidates the 'ounce (gram) of prevention is worth a
> pound (kilogram) of cure' saying.

I don't subscribe to this point of view.

> 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.

Without intending any disrespect, simply choosing to ignore up-front design work is naive. Design is cheap, implementing/testing/debugging is expesnive.

> 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.

I don't argue with XP at all, my quibble is with interpretation and application of the principles.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 9:35 AM

>> 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.

But this misses and is in contradiction to the basic philosophy of XP:-- You can develop with less work, because you can have certainty instead of risk, because the cost of change doesn't increase, so change can be handled immediately instead of attempting to guess to avoid it (to compress my earlier description).

Explicitly planning for change, and designing up-front is a sensible alternative, but it is not XP/agile. It seems fundamentally at odds with it.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 9:53 AM

> >> 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.
>
> But this misses and is in contradiction to the basic
> philosophy of XP:-- You can develop with less work,
> because you can have certainty instead of risk, because
> the cost of change doesn't increase, so change can be
> handled immediately instead of attempting to guess to
> avoid it (to compress my earlier description).
>
> Explicitly planning for change, and designing up-front is
> a sensible alternative, but it is not XP/agile. It seems
> fundamentally at odds with it.

It's not all or nothing? In practice, I find that the number of things that it pays to take into account in advance are very small. In Agile and XP nobody says don't think ahead, you just don't have to act ahead very much. And, yes, the cost of change does increase, but it doesn't go exponential, if you have good design discipline as you go along.

Designing ahead is okay in my book as long as you have the discipline to avoid marrying that initial vision of design. If you marry it, you may miss other design insights as you work. To me, in healthy design work, we're often surprised by our new insights and we have the ability to incorporate them as we have them.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: YAGNI's and Planning for Change

Posted: Jul 15, 2005 10:45 AM

> simply choosing to ignore up-front design work is naive.

It can be, but in the XP case it is backed by a neatly articulated argument (I mean belonging to Beck, I am just reciting it.).

> but you can't ignore the fact that the cost of change increases with complexity and size. Usually over time complexity and size grows, so though the statement is true in theory, in practice it often isn't,

Prima facie, this is a good counterpoint -- aimed at the keystone of XP -- but Beck must mean 'complexity and size' when I said 'time', since he is making an important, strong claim to be the fundamental premise. I can't remember what his support for this was... and it is limited to certain project types...

If by "designs which factor in the possibility of change" (from the original post) you mean designs that are 'formed' significantly by anticipations, then that is counter to XP. But if you mean designs that merely follow very general XP-like guides, like: simplicity, factoredness, disconnectedness, then that is sympathetic to XP.

The purpose of those XP guides is to give software good structure in a very general way. General enough that any effort needed to put it in will always pay off. Any structure tainted with specifics of anticipation has risk, which translates into extra cost in aggregate.

That distinction, nebulous though it may be on close inspection, seems instructive.

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

No dogma

Posted: Jul 15, 2005 2:10 PM

TITLE : NO DOGMA

factoredness, disconnectedness, simplicity. This is fine, this makes sense. Unfortunately one goal of XP is to eliminate complexity when it arises (probably after testing the code: always retesting). Always striving for a simple, solution. I would argue that complexity is at the heart of software engineering. By re-factoring code into many simpler classes and functions reduces the complexity of some change but also introduces the complexity of another sort of change. Functions and classes have interfaces, and lots of functions and classes have lots of interfaces. When you get further down the development cycle and a change is needed to an earlier interface, it might not be easily accomplished as there may be a lot of call points at that time in the code. Preparing for such an incident and implementing it code could be benificial. Not everything in the design of classes and functions can be orthogonal. Reducing one kind of complexity introduces another. Don't let the dogma of XP and anything other than XP fool you. Use what works for you, your company, your software team, whatever.

This presents an interesting insight. How should library code and application code be written?

-Is library code the bricks and application code the mortar?

-Is writing software more like an artist creating a commercial collage? Where the library writer and application writer's lines are blurred. Where the artist constantly ask their clients for approval, or input?

-Is it more like a glass of water? Where a library should be more like water (fluid, flexible) and the application the cup (forming the water). Or a sculptor molding clay?

It is what you make it right?

Object oriented, generic, functional, and structured programming are all solutions to various problems. XP/Agile is a proposed solution to reducing the cost of ONE kind of complexity (the complexity of one kind of change), but it also introduces another. Don't fall into a dogma of attachment to one ideology. See what works and always be open to change. Nothing works forever, not XP. Its not the end all solution. It is not right nor wrong.

I would say that software writers are artisans. Creating solutions to real world problems in creative ways. When an optimal solution is found, it usually needs little change until it is not optimal anymore. Look at sendmail or DNS. Corporations obviously do not like non-profit driven software like this.

I would say the real problem is not the cost of change, but the fact that some change must happen in the first place. There will always be change but some change is just plain stupid. Feature bloat ring a bell? Some change is not the result of growing problems, but growing "perceived needs". The change as a need to push profits. This is human nature right? The hunger for progress, for the elusive perfect solutions to problems that don't exist. Isn't this the heart of a lot of change? This kind of think is also a dogma.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 17, 2005 10:17 PM

"When you get further down the development cycle and a change is needed to an earlier interface, it might not be easily accomplished as there may be a lot of call points at that time in the code."

All that that says is that your refactoring tools are too poor to handle the changes you need to make.

I don't buy this "don't always YAGNI" argument at all. I'm not saying don't plan ahead; I don't plunge into coding something new without an idea of how I'm going to extend it should I need to. But I certainly don't code any of that until the need arises.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: YAGNI's and Planning for Change

Posted: Jul 18, 2005 2:48 AM

> "When you get further down the development cycle and a
> change is needed to an earlier interface, it might not be
> easily accomplished as there may be a lot of call points
> at that time in the code."
>
> All that that says is that your refactoring tools are too
> poor to handle the changes you need to make.

This is only true if you:
a) Have update access to all the code that uses the interface you want to change.
b) Understand the implications of reflecting the interface changes in all said code.
c) Can persuade other users of all that code to go with your changes.

The bottom line is that, in the real world, late changes to a large code base are always more expensive than early code changes to a small code base. Equally, getting it right the first time is better than muddling through with the first solution that passes some first day unit tests and fiddling with it every time a new set of more realistic unit tests are added.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 18, 2005 5:51 AM

This is only true if you:
a) Have update access to all the code that uses the interface you want to change.
b) Understand the implications of reflecting the interface changes in all said code.
c) Can persuade other users of all that code to go with your changes.

So again, you have other XP practices failing, and rather than address those, you're breaking this XP practice. Not really a good path to start down....

Address your real problems. If you still end up breaking practices because your real problems are hard to solve, that's one thing. But I'm not hearing, "This is a bad thing to do, but happened to be the least worst thing for this particular situation, as far as we could figure it out." I'm hearing, "Break this practice, because of fear that this practice might make things harder in the future."

(Oh, and as for b), you don't need to understand the changes that well. Find someone who does have some idea, and rely on your tests. Even if you do make other parts of the system weird, they'll still work, because of the tests, and at some point, if nobody understands it now, someone will go back, clean it up, and make it comprehensible. And probably integrate it much better with the rest of the system to boot. Or nobody will ever touch it again, in which case, who cares?)

Summary: this breaking of the YAGNI rule seems to be driven by fear. Address the fear.

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 18, 2005 9:33 AM

>> "When you get further down the development cycle and a
>> change is needed to an earlier interface, it might not be
>> easily accomplished as there may be a lot of call points
>> at that time in the code."

> All that that says is that your refactoring tools are too
> poor to handle the changes you need to make.

Oh, it seems you stumbled upon a solution to the problem. Integrate your source code into some refactoring tools. I have used Eclipse in my day and it has some pretty spiffy refactoring tools. However, doesn't that say that XP, even though it solves one kind of problem, another one rears its ugly head. Because now we need refactoring tools. It can be argued that refactoring tools can also be developed to deal with the complexity of change for uber large base classes, or some goto spaghetti code. I wonder what a tool that manages goto spaghetti code would look like? In any case it seems that with complexity, we need new tools. And maybe XP is not the solution to minimizing the cost of change in one form, but a path we can take.

We as developers are given more choices than any engineers. There are many "correct" solutions to all sorts of problems. And maybe breaking the path of XP is not really breaking XP, but making a new way of living and coding called XP Extreme ( eXtreme Programming Extreme), or something silly like that.

> I don't buy this "don't always YAGNI" argument at all. I'm
> not saying don't plan ahead; I don't plunge into coding
> something new without an idea of how I'm going to extend
> it should I need to. But I certainly don't code any of
> that until the need arises.

Very good, that seems to work for you. I would argue with you on this one. the "don't always YANGI" rules is not always appropriate. But also, the "I don't code any of that until the need arises" is not always appropriate also.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 18, 2005 10:51 AM

However, doesn't that say that XP, even though it solves one kind of problem, another one rears its ugly head. Because now we need refactoring tools.

No, you've got it backwards. You always needed refactoring tools to easily do refactorings like this. You were just too scared to do them before because you didn't have the tests to support doing refactorings like that.

As far as the YAGNI thing, well, let's just say that in the last five years that I've been learning XP practices and doing XP, I've never seen a case where XP was working and that rule didn't work. But I've often seen cases were people said, "Oh, surely this part of XP can't be right," not done it or stopped doing it, and watched things start to fall apart around them.

So, tell me, all you people who have consciously decided to do a non-YAGNI thing recently: were all your other XP practices working?

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 18, 2005 2:08 PM

> No, you've got it backwards. You always needed refactoring
> tools to easily do refactorings like this. You were just
> too scared to do them before because you didn't have the
> tests to support doing refactorings like that.

Yes, refactoring tools at some level were always needed. I am not arguing against their use. Software today has become too complex without them right? XP is a way of working that tries to reduce the cost of changing a large code base right? One way to reduce that cost is through automation. Refactoring has always been a part of software and XP seems policy seems to be, refactor early and often. Yet it becomes obvious that when the software gets bigger, even with constant refactoring, change is still costly. XP tries to reduce the cost of changing the implementation and structure of code. Yet refactoring cannot be the only solution to this problem. XP obviously requires constant tests, constant client feedback, constant refactoring until the product is correct. Yet I believe the code you right, not just the way you right it, should be flexible enough to facilitate future change. It doesn't have to be pretty, but it can sure be beautiful to see code that performs well under change.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: YAGNI's and Planning for Change

Posted: Jul 19, 2005 12:29 AM

This answer is not really worth replying to, but here goes:

> So again, you have other XP practices failing

No. I have a single entry in this debate and made no reference to failing XP practices.

> Address your real problems.

This is patronising. I'm addressing the problems raised in the article. My 'real' problems, such as they might be, are irrelevant.

> But I'm not hearing, "This is a bad
> thing to do, but happened to be the least worst thing for
> this particular situation, as far as we could figure it
> out." I'm hearing, "Break this practice, because of fear
> that this practice might make things harder in the
> future."

Inventing quotations and presenting them as if they are mine is a nonsensical way to make a debate.

> (Oh, and as for b), you don't need to understand the
> changes that well. Find someone who does have some idea,
> and rely on your tests.

If you don't understand the changes you're making, how do you tell if your tests are sufficient to cover your ignorance?

> Even if you do make other parts of
> the system weird, they'll still work, because of the
> tests, and at some point, if nobody understands it now,
> someone will go back, clean it up, and make it
> comprehensible. And probably integrate it much better with
> the rest of the system to boot.

This is quite a extraordinary statement. You development philosophy appears to be nothing more than getting code out of the door that passes some tests, with a blind hope that those tests will cover you, even if you don't understand what you are doing. Any problems that arise from your code will be someone elses.

> Or nobody will ever touch it again, in which case, who cares?)

Have you considered that if nobody touches your code, it isn't necessarily a vindication of what you have written.

> Summary: this breaking of the YAGNI rule seems to be
> driven by fear. Address the fear.

Again more patronising nonsense. Software development isn't some sort of exercise in macho chest thumping.

Questioning the premises of a software development style is not a symptom of fear but of open thinking. On the other hand, patronising and accusing those who question - of being driven by fear - is not.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Re: YAGNI's and Planning for Change

Posted: Jul 19, 2005 12:54 AM

Let's get back to my original point here: YAGNI works when you're doing all of XP.

If you're not concerned with XP practices, YAGNI isn't going to work for you. Well, duh! Who said it would?

For example, if you don't trust your tests to cover change to the system, you're not doing XP very well, are you?

As for this comment:

You development philosophy appears to be nothing more than getting code out of the door that passes some tests, with a blind hope that those tests will cover you...

No. You want to believe that because if you instead believe that I can deliver software when I say I will, make the software very reliable, and still rototill like mad wherever I want in the code with complete confidence, at any time, I might well be right about this issue.

I don't even see where the argument is. I have done this. It does work. I've seen YAGNI fail, and I've told you how and why it fails. If you've never seen it when it is working, you've only ever seen half the story.

DouglasDD

Posts: 7
Nickname: douglasdd
Registered: Oct, 2004

It's the "don't know *squared_" that is the problem...

Posted: Jul 19, 2005 8:22 PM

As a former boss of mine told me:
"There's three parts to every project:
(1) what you know,
(2) what you don't know,
(3) what you don't know that you don't know"
...and it's this third one (the don't know squared) that messes up most developers because that is the change of requirements (or library bug, or other completely unnexpected plot twist) that blind-sides them while they were carefully abstracting around the items in category #2, so that they could deal with changes in them.

When the domain is a familiar one, or the customer is me, then the effects of #3 may be minimal. In these projects, yes, the anticipatory work that goes into flexible design can pay off.

But when I'm working on a project in a domain that is new to me, or with one or more new technologies / frameworks, etc, (which let's face it is 80+% of the time!), then the risk of #3 is signififant. Therefore the risk is much higher that my anticipitory design flexibility (around things in the #2 category) does not help me to dodge the bullet that comes out of left field (#3). In fact some of that #2-related flexibility may make my life considerably harder if / when I have to deal with the dreaded don't know squared!

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

Re: It's the "don't know *squared_" that is the problem...

Posted: Jul 19, 2005 10:13 PM

" I believe the code you right, not just the way you right it, should be flexible enough to facilitate future change."

I agree with you Douglas D. D. in all respects. Writing code that can handle change or dealing with code to handle change are solutions that have a harmony with each other. One works here, another works there. It does take that gut feeling to choose what works. Experience here is priceless. Yet we must strive to never get dogmatic. This is why I have a quarell with the Java language. A multi purpose language that uses exclusively the Object-Oriented paradigm. Object orientation is not the solution to all problems. So I constanly see many hacks in java to do things java was not ment to do. Same with XP, It would bother me for people or a company to use XP on ALL of their projects. Maybe it would be more usefull to use the parts of XP that are needed and parts of another way of working that are needed.

we as designers and programmers have choices. Do we use YAGNI? XP? OO? SEX? KISS? etc... Or better yet, how can we mesh those together.

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

Previous Topic

Next Topic