46

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:

KeesDijk
  • 8,918
  • 4
  • 35
  • 41
  • Shouldn't also the title be `SOLID principle vs YAGNI`? – Wolf Jan 09 '15 at 12:33
  • 2
    @Wolf: It is a plural "SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the 'first five principles' named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design." – logc Jan 09 '15 at 13:26

6 Answers6

61

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.

Adam Lear
  • 31,939
  • 8
  • 101
  • 125
  • 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
  • `YAGNI and SOLID coexist` good conclusion. Although it might be a good starting point – Wolf Jan 09 '15 at 14:20
  • It seems that maybe a hunch is needed sometimes. You have to know where you might begin to see lots of changes to know where your levels of abstraction vs the plumbing stop and start. – johnny Aug 09 '17 at 15:18
22

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.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • Yeap, agree.. there is no silver-bullet approach that fits every scenario. – Yusubov Dec 14 '12 at 23:09
  • Your `make sure the pieces of the bridge fit together` is by far not as evident as `can be maintained over time`. – Wolf Jan 09 '15 at 14:01
  • 1
    Basically, SOLID is what will enable you to transform that wooden bridge to a full on 1 mile long steel bridge capable of supporting an armored platoon without doing a full rewrite or by just sticking on hack after hack. – sara Jul 03 '16 at 07:10
  • @kai, that's a false premise. If you need a bridge that spans 1 mile, then you engineer a bridge that spans 1 mile. If you need a bridge that spans 5 feet, you build a bridge that spans 5 feet. Don't get me wrong, SOLID principles are very helpful, but it takes more understanding of them to know which principles aren't necessary for the problem at hand. 9 times out of 10, that extra mile is never needed. – Berin Loritsch Jul 03 '16 at 19:42
  • 1
    @BerinLoritsch which is why I agree that if you need 5 feet, you build 5 feet, but you DON'T build 5 feet by ducttaping a couple of 2x4s to the ground. you do what you need, and you do it well. (although the analogy is kind of falling apart) – sara Jul 03 '16 at 20:00
  • @kai, the point you are missing is that you don't always need steel reinforced concrete on every bridge. You use the appropriate tools for the job. No one is suggesting you don't do any engineering. That is ludicrous. You do the appropriate amount of engineering for the task at hand. – Berin Loritsch Jul 04 '16 at 22:09
  • @BerinLoritsch I am not missing the point, you just reiterated what I wrote more or less. – sara Jul 08 '16 at 07:36
  • A wooden bridge spanning a 3 foot wide creek will colapse if built poorly. – Tulains Córdova Aug 05 '16 at 14:04
  • @TulainsCórdova, no one is suggesting to build it poorly. Simply to use the right tools for the job. Please take time to understand the spirit of what I said without getting hung up on the doctrine of SOLID. Not every principle of SOLID is appropriate for EVERY job. The more experience you have, the more you know which parts of SOLID to apply and which to omit for the specific problem set. – Berin Loritsch Aug 05 '16 at 15:01
  • @BerinLoritsch You are right. You didn't suggest that. On the other hand what I tried to state, perhaps unsuccessfully, was that YAGNI and SOLID are not mutually exclusive like your answer seems to imply. The bridge example is more suitable for things like "framework vs no-framework", "IDE vs no-IDE" or something similar. After all, frameworks and IDEs are tools whereas YAGNI and SOLID are principles, guidance. – Tulains Córdova Aug 05 '16 at 15:22
  • @TulainsCórdova, please reread the last paragraph. – Berin Loritsch Aug 07 '16 at 01:18
  • "If you blindly apply the principles of YAGNI or SOLID, you can hurt yourself later on. " In reply, @sara said it already. SOLID is some insurance against hurting yourself later. The question is, were the upfront premiums priced right for the risk. Also, while managing the risk, they don't eliminate it. – Adamantish Sep 21 '21 at 13:11
10

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.

George Stocker
  • 6,388
  • 2
  • 31
  • 55
  • 1
    Isn't this mixed up? What about this: Properly apply SOLID principles to handle the complexity of self-healing cars, or apply YAGNI as long as your cars are still so simple that they will never break (or - alternatively - so cheep that they can be just thrown away). – Wolf Jan 09 '15 at 13:51
  • 3
    @Wolf the SOLID principles don't say WHAT you should do, only HOW. if you already decided that you want self-healing cars, then you can apply the SOLID principles to that code. SOLID doesn't say whether or not a self-healing car is a good idea though. That's where YAGNI comes in. – sara Jul 03 '16 at 07:11
  • Often times throw-away applications aren't. – Tulains Córdova Aug 05 '16 at 14:05
  • "Self-heal" is good. "Before the customer asks for it," is also good because I think the whole idea, if you listen to Uncle Bob, is for places that make a profit and anticipate the needs of the customer and having a viable business that can respond to needs because they change. Lots of people get annoyed at Uncle Bob because he doesn't get right to the programming, but he is telling you, most of the time, why it matters to use SOLID, not just how. – johnny Aug 09 '17 at 15:21
  • *"SOLID principles aren't needed when it's a throw-away application"*. I think that SOLID principles are a good habit, so even if it's a throw away application, you're training yourself for when you need to write a large application, so there can be a benefit of following SOLID principles. – icc97 May 05 '18 at 15:51
  • Disagree. When companies use Ruby on Rails they do so to achieve high velocity, usually at the cost of technical debt. Much of how Rails achieves this is by going hard on YAGNI and encouraging devs to absolutely ignore most of SOLID. Lots of SRO violation, implicit imports over explicit DI, etc... The trade-off is real. It allows conventional APIs and web apps to be created with minimum imaginable code while a good number of the more detailed best practices come for free under the hood. The pain comes later when the company find they have 3000 line God model which touches everything. – Adamantish Sep 21 '21 at 13:19
4

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!

Community
  • 1
Brandon
  • 437
  • 2
  • 5
2

There is a quote attributed to Einstein (probably a variation on a real one):

“Everything should be made as simple as possible, but no simpler.”

And that is more or less the approach I take when confronted with the SOLID vs YAGNI tradeoff: apply them alternatively, because you never know if a program is 'throw-away' code or not. So, just add a layer of dirt that works, then polish it to a cleaner interface ... and repeat until you converge to the right level of entropy. Hopefully.

logc
  • 2,190
  • 15
  • 19
  • Good point: `you never know if a program is 'throw-away' code` - well, I think the *alternatively* idea isn't that good. – Wolf Jan 09 '15 at 14:03
  • @Wolf: yes, I was expanding on the order of steps I think is best (summarized in the 'First make it possible, then make it beautiful, then make it fast' slogan), but then I thought ... YAGNI :) – logc Jan 09 '15 at 14:08
1

There's many ways to design a program for a given problem; SOLID is an attempt to identify the properties of a good design. Proper use of SOLID is supposed to result in a program that's easier to reason about and modify.

YAGNI and KISS are concerned with feature scope. A program that solves more kinds of problems is more complex and abstract. If you don't need that generality, you've spent time and effort creating code that's harder to understand and maintain but offers no added value.

A program that's designed well isn't necessarily focused on only the features it needs. A program that's focused only on the features it needs isn't necessarily well designed. There is no trade-off, just two orthogonal axes in the decision-making space. An ideal program is both modular and has only essential features.

Doval
  • 15,347
  • 3
  • 43
  • 58