Vukoje.NET

Vukoje's blog about software development

YAGNI, sain programmer's principle

As programmers fight every day with deadline pressures to deliver meaningful software to customers on time, there is one code principle that can speed up and simplify their effort. This principle is called YAGNI, which is short for "You Aren't Going To Need It".

YAGNI is the principle in extreme programming stating that programmers should not add functionality until it is necessary, meaning that you should always implement things when you actually need them, and never when you just foresee that you need them.

 

YAGNI assitant

The reason for enforcing this principle is that anticipation in software is very hard and usually leads code off track, while also spending valuable resource - time. Anticipation leads to half baked implementation that you maybe didn't need in the first place, and that implementation can turn out to be constraint on implementing some vital functionality that you really need. So what you have is lose-lose situation, you wasted your resources and made situation harder for yourself.

Ron Jeffries, one of the 3 founders of extreme programming, said it like this

Often you will be building some class and you’ll hear yourself saying "We’re going to need...".Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them.

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

You’re not gonna need it!

 

The art of delaying

 

Any problem can be solved if you can delay it long enough, but of course you can't always delay things.

You must remember those situations where Microsoft or some other vendor solved all your problems shortly after you implemented your custom solution. These are really painful moments because usually vendor does it much better than you did and it usually comes free of charge.

Or maybe you remember those painful to implement tasks that altered your core architecture before you found out that they weren't really that important for business and that they will probably be thrown away?

Hart of the justification of YAGNI is that many of these potential needs end up not being needed, or at least not in the way you'd expect. By not doing them until they are really needed you'll save a good deal of effort.


YAGNI and The Big Design

 

Jeff Atwood said it like this on his Coding Horror:

As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate OOP frameworks around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

To make design of your whole big project before you start coding it you need to know/assume most of the requirements. This is the only way you can plan application design that will last for next few years. Reason why YAGNI won't let you create big upfront designs is because they are almost always wrong. They are wrong simply because it is impossible to foresee all user requirements and think of all possible variations of Use Cases and potential design problems. Even if you could do all of this, requirements will change before you finish your project. What you should do instead is start from some basic design that will evolve to finally product. Basically you should design a minimum that works, without over engineered grand designs of feature.

If you haven't already, go and read Martin Fowler's article "Is Design Dead?" that has became manifesto of agile development.


What about prototypes?

 

YAGNI is in direct conflict with concept of software prototyping, but the difference is that when you build a prototype you know that you are doing it because you don't know the real requirements (you know that you don't know). This is also why you should throw away your prototypes, or at least evolve them to real code.


Do you have any sad story that could be avoided by YAGNI?

Do you apply YAGNI to your shopping?


Comments (3) -

  • Milica

    12/7/2009 7:29:04 AM | Reply

    Good article. As for applying YAGNI to shopping, I might need to start Tong

  • Aleksandar Mirilovic

    1/25/2010 5:22:58 AM | Reply

    Very good text I have to force everyone in my company to read this.
    Everyone who does any kind of programming is going to be touched with this story.
    I agree with this principle but it is hard for me to follow it.
    Colleague of mine and I work as a team, he literally follows this principle, so it is my job to clean after him and do code refactoring all the time.
    Yesterday a strange thing happend to me, something I coded before (did't really need it at that time) I actily used, that fealing was so strange for me as if it never happend before, and I always write code with predictions.
    Software design and foreseeing gives you false security that will delay your justified fear until the moment when it's to late!

  • vukoje

    1/25/2010 3:23:05 PM | Reply

    @Aleksandar

    "Software design and foreseeing gives you false security that will delay your justified fear until the moment when it's to late!"

    Wow, those are some very inspiring thoughts and I fell that they are very true. I must use this somewhere Smile

Loading