Weblogs Forum

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
YAGNI

36 replies on 3 pages. Most recent reply: May 28, 2012 9:11 AM by Manny Bonet

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 36 replies on 3 pages [ « | 1 2 3 | » ]

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: YAGNI

Posted: Mar 2, 2004 6:51 AM

> I'm left wondering what the big deal is. Why do people
> get so upset when we say YAGNI, but not when we say KISS.
> What is it about YAGNI that is so offensive and contrary.
> . To me they mean the same thing.

I've inhereted a lot of projects where YAGNI seems to be the polar opposite of KISS. One example which is perpetually vexing is a security module on a multidimensional database application I maintain. At the time it was written they only needed security on one dimension, so in the spirit of YAGNI, the security module was only written for that one dimension. They didn't need security on the other dimensions, so why bother planning for it and architecting the applcation in such a way that it could be handled later?

Occasionally customers want security on some other dimension. As the product is now in legacy mode, this isn't much of an issue anymore, but short of rewriting the application (that wasn't going to happen, even if I wanted it to), there was little that could be done to meet this request because of how horribly brittle the code is.

The idealized version of YAGNI talked about in this thread seems to have little resemblance to the real world instances I've encountered. If you think of YAGNI as a tree, you guys are talking about the Platonic form of YAGNI in all its perfection. I have seen the manifestion that is the equivalent of Charlie Brown's Christmas Tree :-(

I don't know if anybody else has had this experience, but that would account for my knee jerk reaction of distaste to the mention of YAGNI.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 2, 2004 9:41 AM

a kind of humility that I am bad at predicting the future

And in a spirit of humility, we question, we do not assert.

And questions flow more easily from "Always implement things when you actually need them, never when you just foresee that you need them."

Why do we need to do this now?

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: YAGNI

Posted: Mar 2, 2004 11:57 AM

If KISS and YAGNI are synonymous, why invent a new acronym when, yeah, you guessed it -- YAGNI.

Anyway, I think many people object to YAGNI, because it comes off as childish and over-simplistic. If what it really means (which is a stretch). The examples given of YAGNI in fact, seem to go counter to the literal interpretation of the phrase. If that's the case, then the phrase is wrong (some of the suggestions in this thread sound much better).

It just seems like common sense to avoid over-architechting while at the same writing your code in a way that allows it to be improved tomorrow. There are many more interesting and subtle examples of where this is advantageous, than the facile database example.

These guys obviously don't "get it": http://www.parc.com/research/csl/projects/obje/

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: YAGNI

Posted: Mar 3, 2004 3:44 AM

> If persistence was not considered int the design,
> following the YAGNI idea, why were there interfaces that
> could be used to implement persistence? In other words,
> why did you bother to write interfaces that would allow
> you to implement something you assume is not needed?
>
That's what I was wondering too.
YAGNI clearly says to not code something that's not needed NOW.
The persistence interface framework wasn't needed NOW, but in the head of the programmer was the idea that it might be needed in the (near) future so he incorporated it.
Following YAGNI to the letter would have had him deliberately not implement the framework and get bitten in the back a bit later when it was needed and half the program had to be rewritten to make use of it.

> Every time I try to follow YAGNI and end up needing
> something I thought I wouldn't need, I have to refactor a
> lot of code to implement the change. There seems to be a
> missing part of YAGNI that says "Allow for it just in
> case you need it in the future". Am I missing
> something?
No, you're just encountering a clash between theory and practice.
Theoreticians have all these nice glossy ideas that don't work in the real world because the real world isn't perfect.
What you describe is a pragmatic look at YAGNI which I support and try to practice.
I write code in such a way that it's easy to refactor for changing conditions, even if I don't know for certain what those conditions will be.
I started middle of last week with no code, then wrote a single small sub-application. Using that I wrote the next slightly larger sub-application, etc. etc.
In the process the first one has undergone minimal changes only as I needed a few extra parameters in some overloaded functions, but because I anticipated overloading those functions I could add those by just changing the method signatures and didn't have to touch the actual code at all.

Dale Emery

Posts: 4
Nickname: dhemery
Registered: Feb, 2004

Re: YAGNI

Posted: Mar 3, 2004 11:45 AM

Jeroen said:
> YAGNI clearly says to not code something that's not needed NOW.

The words "you aren't gonna need it" don't say only that, they say something more. They say that you aren't gonna need it -- that is, not only do you not need it now, you also won't need it later. If you take YAGNI literally, "you aren't gonna need it" somewhat overstates the case.

People who have absorbed some of the XP philosophy understand not to take YAGNI literally. They've learned that when XPers say YAGNI, they mean don't "code stuff you don't need right now." People who have not (yet) absorbed that philosophy may be reacting to the more literal interpretation.

Dale

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 3, 2004 12:24 PM

People who have absorbed some of the XP philosophy understand not to take YAGNI literally
Say what you mean; mean what you say. (Or create confusion.)

Dale Emery

Posts: 4
Nickname: dhemery
Registered: Feb, 2004

Re: YAGNI

Posted: Mar 3, 2004 12:50 PM

Bill said:
> I think Charles' post pretty much sums up what lesson I
> took away from YAGNI, which is basically a kind of
> humility that I am bad at predicting the future.

That's what YAGNI means after you learn what it means.

Unfortunately, before people learn what it means, they might think it means what it says. And YAGNI, if taken literally, conveys exactly opposite of the meaning you've learned. "You aren't gonna need it" is a prediction, and a pretty unhumble one at that.

Dale

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 3, 2004 8:32 PM

> I think Charles' post pretty much sums up what lesson I
> took away from YAGNI, which is basically a kind of
> humility that I am bad at predicting the future. I think
> the database example that the XP folks always seem to use
> may turn some people off for the same reason the XP folks
> use it. Usually, the answer to the question of whether or
> not you're going to need a database seems plainly obvious
> to most people. I don't think I've ever been wrong when
> deciding up front whether or not I would need a database.
> For the proponents of YAGNI, this is a good example
> because it shakes the foundations of people's confidence
> in their ability to predict the future. But for many, it
> comes across as too extreme.
>
> I have also had YAGNI thrown at me to "diss" plans I had
> to implement some feature. YAGNI should be applied with
> some thought and judgement. You *are* going to need some
> things, otherwise you'll have nothing. Unless you want to
> be a Zen master, I guess. Perhaps I'm more of a moderate
> programmer than an extreme programmer, but I think you
> need to place some bets. YAGNI can help by reminding you
> that you're ability to predict the future is poor. That
> can help you manage risks and make better choices. But you
> shouldn't avoid all risks. You have to use your judgement
> and place your best bets.

The interesting thing is that often things turn out better when you pretend that you "won't need it." I wrote the InMemoryPage stuff in Fitnesse that Bob was talking about, and I did it just because I didn't want to muck with files while writing tests. I just didn't want to solve that problem yet. As a result, the rest of the code didn't have to care about the file system either.

I could've ended up with that interface in other ways also, it's just good design practice to separate concerns, but by pretending that.. "hey, we don't need to go to the disk" nice things happen.

I've actually had the database thing happen to me once. I was working on a online auctioning system and the thought was that we would need a database for registered users. I convinced the team to pretend we weren't going to use a database, just access an object for information. When the system went into production we realized that the number of registered users was going to be so low it was easiest just to back it with a flat file. So, it's happened. I'd never argue its typical :-)

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 3, 2004 8:54 PM

> > ... So when one of our users decided that he'd rather
> > have the pages in a database than in flat files, it
> took
> > him no more than two days to write the DB back end.
> The
> > interfaces were already there, and all he had to do was
> > implement them.
>
> If persistence was not considered int the design,
> following the YAGNI idea, why were there interfaces that
> could be used to implement persistence? In other words,
> why did you bother to write interfaces that would allow
> you to implement something you assume is not needed?

Here is what happened, if I remember correctly. Bob & Micah were working on Fitnesse and they knew they needed pages so they came up with an interface named WikiPage that could provide text content. They mocked it out in their tests, just returning strings when they needed strings.

We needed pages to be hierarchical so I created a class named InMemoryPage that implemented WikiPage. I added methods to WikiPage to allow clients to get from one page to another. All of this was happening in memory.

When it was time to really work with the file system, I introduced a superclass for InMemoryPage called RawPage and I pushed up all of the logical bits, leaving only some allocation related things down in InMemoryPage. Then I subclassed InMemoryPage, making a class named FileSystemPage which overrides some parts of RawPage to persist and retrieve things at the right times.

Since this was all happening behind the WikiPage interface, the rest of the code didn't care. In one place in the application you can create the root page as either an InMemoryPage or a FileSystemPage and everything works.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 4, 2004 12:08 PM

I think the database example that the XP folks always seem to use may turn some people off for the same reason the XP folks use it. Usually, the answer to the question of whether or not you're going to need a database seems plainly obvious to most people.

Smalltalkers have a wealth of experience with this issue. Most Smalltalks provide a very simple way of saving a memory snapshot to an image file. (The image provides a fast way to persist the development environment, class libraries, tools, applications...)

In Smalltalk the simplest way to persist application data is to save the image. Starting the application loads the saved memory snapshot (byte code and data).

From Smalltalks persistence is free perspective, "are we going to need a database" is a question about data volume & reuse (why re-implement concurrency-control, recoverability, reporting...); and for the trivial data volumes discussed here the "plainly obvious" answer is of course we don't need a database.

The interesting thing is that often things turn out better when you pretend that you "won't need it."

And can things also turn out worse "when you pretend that you won't need it"?

Why is persisting 600 unit tests being glorified as a database example?

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 4, 2004 1:16 PM

> The interesting thing is that often things turn out
> better when you pretend that you "won't need it."
>
> And can things also turn out worse "when you
> pretend that you won't need it"?

It's possible. The trick is to keep things simple, and when you discover something you think you might need, think about it. Will it be more expensive to add later? Will acting as if you won't have to do it shortchange you of possibilities later? If it won't, starting simple has its benefits.

> Why is persisting 600 unit tests being glorified as a
> database example?

I think you misunderstood. The application has about 600 unit tests and the application needs to persist things, but it doesn't need to persist its own tests.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: YAGNI

Posted: Mar 5, 2004 9:22 AM

> > And can things also turn out worse "when you
> > pretend that you won't need it"?

It's possible. The trick is to keep things simple, and when you discover something you think you might need, think about it. Will it be more expensive to add later?

So we have another answer to the original question "Why do people get so upset when we say YAGNI?"

People get upset because asserting "You aren't going to need it!" is just as thoughtless as asserting "You are going to need it!".

Don't we expect engineering decisions to come with analysis and justification?

I think you misunderstood. The application has about 600 unit tests and the application needs to persist things, but it doesn't need to persist its own tests.

My ability to misunderstand sometimes seems boundless ;-)
Now I've read again that it's the wiki pages that are being persisted, I'm just as puzzled by the use of this as an example of are you going to need a database.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: YAGNI

Posted: Mar 5, 2004 5:31 PM

"Why do people get so upset when we say YAGNI?"

The awful melodramatic music? The hair? The mustache?

Just look at this and tell me you don't get upset:

http://www.yannimusic.net/

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: YAGNI

Posted: Mar 8, 2004 3:36 PM

Well, I think folks who must write a LOT of software eventually, by necessity, realize that working today on something you're not going to need tomorrow, is pretty much an impossibility because of the time and effort involved.

But lately I also realized that the day after tomorrow always comes a lot sooner that we'd like to think. And when the day-after-tomorrow comes, a lot of code that we initially didn't need must, eventually, be written by someone. And it often turns out, at least in my experience, that that day-after-tomorrow code is a lot more complex and intricate than the initial code centered around business logic.

Take database access, for instance. A database is not only a persistence mechanism, but is also often a concurrency control tool. For instance, you may have 5 copies of your application running on a network. Say, you use some UI component that, by necessity, caches a lot of data (say, customer orders in a table model). As folks use the software, that data changes, and there must be some infrastructure that keeps all those UI data caches in synch. In that situation, to think about data management as an afterthought, is tantamount to just postponing one of the big issues in the application.

Or, if you have a database, consider the issue of managing reliable database connections in the presence of unreliable networks. That issue becomes critical only when you decide to deploy your application in the field, but then it surely becomes an extremely important issue. Again, it's possible, and may even be a good thing, to postpone that issue until after the business domain is clearly understood. But I'm finding that such "infrastructure" issues end up taking up a very significant time of an application's development effort.

In general, I think the YAGNI notion is attractive in a consulting or IT department situation where people have deadlines and management issues to deal with, including the need to show something to the customer as soon as possible.

As an ISV, however, I can say that my customers care little about actual release dates, or how much effort (resources) are put into an application or a release. What they do care about is often those infrastructure issues that nobody likes to talk about, nobody cares to discuss, but that make or break the success of an app in the real world. As a consultant, we can deliver a product, get management sign-off, and get our consulting check. As an ISV, however, that's just the beginning - you end up having to support customers, and in that situation, it is wise to think from day one about issues that might just prevent your application from gaining wide acceptance the day after tomorrow.

J. B. Rainsberger

Posts: 12
Nickname: jbrains
Registered: Jan, 2004

Re: YAGNI

Posted: Apr 24, 2004 9:23 AM

Better Software Magazine, April 2004 issue, feature article. You go, Bob!

Flat View: This topic has 36 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic