Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When do the SOLID principles become YAGNI?

As programmers we make trade-offs all the time, between complexity, maintainability, time to build and so forth. Amongst others, two of the smartest guidelines for making choices are in my mind the SOLID principles and YAGNI. If you don't need it; don't build it, and keep it clean.

Now for example, when I watch the dimecast series on SOLID, I see it starts out as a fairly simple program, and ends up as a pretty complex one (end yes complexity is also in the eye of the beholder), but it still makes me wonder: when do SOLID principles turn into something you don't need? All solid principles are ways of working that enable use to make changes at a later stage. But what if the problem to solve is a pretty simple one and it's a throwaway application, then what? Or are the SOLID principles something that always apply?

As asked in the comments:

share|improve this question

4 Answers 4

up vote 24 down vote accepted

It's always difficult to judge an approach based on a screencast, since the problems picked for demos are typically so small that applying principles like SOLID quickly makes it look like the solution is completely overengineered.

I'd say SOLID principles are almost always useful. Once you become proficient with them, using them doesn't seem like something you have to deliberately think about. It just becomes natural. I've seen many throwaway one-off apps become more than that, so I'm now afraid of saying that I'm going to throw something away, because you just never know.

The approach I usually take is that if I'm writing a simple app for a particular task, I'll sometimes forgo big name principles in favour of a few lines of code that work. If I find that I'm coming back to that app to make further changes, I will take the time to make it SOLID (at least somewhat, since a 100% application of the principles is rarely feasible).

In bigger apps, I start small and as the program evolves, I apply SOLID principles where possible. This way I don't attempt to design the whole thing upfront down to the last enum. That, to me, is the sweet spot where YAGNI and SOLID coexist.

share|improve this answer
    
This is pretty much what I think also. As a remark I don't judge by the screencast, I just think it is a nice example of how software can grow when applying SOLID. –  KeesDijk Dec 30 '10 at 15:16
    
Good point. Any demonstration will be skewed to demonstrate or exacerbate the problem at hand. Essentially, its the whole idea of taking an idea to its fullest conclusion to prove it is a falacy. A premise that in itself can be abused. –  Berin Loritsch Dec 30 '10 at 15:50

Think about the problem at hand first and foremost. If you blindly apply the principles of YAGNI or SOLID, you can hurt yourself later on. Something that I hope we can all understand is that there is no "one" design approach that fits all problems. You can see evidence of that when a store sells a hat advertised as "one size fits all", but it doesn't fit your head. It's either too big or too small.

Instead, it's better to understand the principles and problems that SOLID is attempting to address; as well as the principles and problems that YAGNI is attempting to address. You'll find that one is concerned with the architecture of your application and the other is concerned with the development process as a whole. While there can be overlap in some cases, they are distinctly different problems.

YAGNI (You Ain't Gonna Need It [quaint American acronym]) is concerned with saving developer time adding steel re-inforced concrete foundations to a bridge that is only intended to span a 3 foot wide creek when a simpler wooden bridge will do just fine. If we are spanning a mile wide river and needing to support several tractor trailers, of course we would need that extra foundation work. In essence, YAGNI is telling you to look at the bigger picture and design for the current needs. It is addressing the problem of making something too complicated because we are anticipating a number of potential needs that the customer hasn't identified yet.

SOLID is concerned with how we make sure the pieces of the bridge fit together properly, and can be maintained over time. You can apply SOLID principles to the wooden bridge as well as the steel re-inforced concrete bridge.

In short these two concepts are not necessarily in conflict with each other. When you come across a situation where you believe that they are, it's time to take a look at the big picture. Depending on your conclusion, you might decide to do away with a portion of the SOLID principles or you might decide that you really do need it.

share|improve this answer
    
Very nicely put, thank you. Totally agreed. –  KeesDijk Dec 30 '10 at 21:30
    
Yeap, agree.. there is no silver-bullet approach that fits every scenario. –  Yusubov Dec 14 '12 at 23:09

Nothing always applies! Don't Let Architecture Astronauts Scare You! The important thing is to try and understand what problems these principles are trying to address so that you can make an informed decision about applying them.

Recently I was trying to understand when I should use the Single Responsibility Principle (here's what I came up with.)

Hope this helps!

share|improve this answer

SOLID principles aren't needed when it's a throw-away application; otherwise they are always needed.

SOLID and YAGNI aren't at odds: Good class design makes the application easier to maintain. YAGNI just states that you shouldn't add the ability for your application to be this configurable monstrosity that can do everything under the sun -- unless it actually needs it.

It's the difference between a Car class that has well defined boundaries (SOLID) and a car class that has the ability to self-heal (YAGNI) before the customer asks for it.

share|improve this answer
    
+1 for the Car analogy. –  Anna Lear Dec 30 '10 at 15:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.