loading...
Cover image for My 5 Favorite Software Design Principles 

My 5 Favorite Software Design Principles 

Jeremy Morgan on August 10, 2019

I'm looking for honest feedback on my content. Please comment or reach out to me on Twitter! Building software is easy. Building well designed, go...
pic
Editor guide
Collapse
nathanheffley profile image
Nathan Heffley

Great article! The only thing I have to say is that I'm one of those people who says that repeating something twice isn't enough to justify abstracting it out just for the sake of being DRY. In only the most simple programs will something that you use a third time be exactly the same as the first two times you did it. Waiting until you've repeated yourself three times helps you know what it is that you're actually repeating.

Collapse
ssimontis profile image
Scott Simontis

Context is crucial too...you can have the same code show up in different places with completely different contexts which looks repetitive, but it makes no sense to de-duplicate something that crosses system boundaries.

Collapse
jeremycmorgan profile image
Jeremy Morgan Author

Absolutely right. Sometimes you can have the exact code verbatim and working off two different input/outputs. One of those implementations may change without the other so by de-duping and putting into a method you can be creating a regression.

This is why software engineering is so fun! (not saying it sarcastically)

Thread Thread
jsco profile image
Jesco Wuester

duplication is better than the wrong abstraction :D

Thread Thread
jeremycmorgan profile image
Jeremy Morgan Author

most of the time, yes

Collapse
jeremycmorgan profile image
Jeremy Morgan Author

I can live with that. I usually stop and abstract when I find myself repeating something the 2nd time because I don't want it to spiral out of control. I've been criticized in code reviews for abstracting too much into methods, some of them only having one or two lines. I abstract things early which may be repeated... that arguably can be another form of YAGNI lol.

But I do like the "do one thing and do it well" philosophy. 3 times is reasonable.

Collapse
citizen428 profile image
Michael Kohl
Thread Thread
jeremycmorgan profile image
Jeremy Morgan Author

Guilty. But lots of abstractions means faster running unit tests, right?

Thread Thread
citizen428 profile image
Michael Kohl

Not sure if you're sarcastic here, but if you're not our units under test originate in very different testing philosophies.

Collapse
jessekphillips profile image
Jesse Phillips

Yeah I was recently being told to go back and learn my basics in SoCs and stoics because I challenge the notion of blindly following patterns and abstractions.

Abstraction create layers and can lead to obfuscation if the wrong thing is being abstracted. This "right" thing can be extra hard to identify, so this is where YAGNI creates conflict with Dry or SoC.

Collapse
phlash909 profile image
Phil Ashby

Welcome to level <n+1> :)

As you have neatly expressed, it's always a compromise between YAGNI and DRY/SOC. I like to aim for a sweet spot where it just passes the tests, and someone else (always yourself in 3 years time!) can maintain it without swearing at you!

Collapse
twigman08 profile image
Chad Smith

Just to give even more advice to some beginners: don't focus too much on making sure you're hitting these things. Your first job is to write the software. Spending too much trying to make sure you're hitting all these can keep you from your main goal: finish the project.

Most of the time these things will just happen with experience. I mistakenly spent entirely too much time trying to meet one of these 5 principles before and it kept me from actually finishing projects. As you grow as a developer these things will develop naturally in your code most of the time.

Collapse
lietux profile image
Janne "Lietu" Enberg

There is no difference between "software engineer" and "software developer" other than that some organizations like one term over the other. AFAIK in some parts of the world the term "engineer" is also protected and thus "developer" is preferred.

Collapse
jeremycmorgan profile image
Jeremy Morgan Author

While I agree many organizations abuse the terms, there is a clear difference.

It's similar to a bricklayer and the architect drawing up plans. While they're both essential to creating the building, each has their own craft to it. This is exactly why some people enjoy being developers and staying developers rather than move to the engineering side of things.

Collapse
lietux profile image
Janne "Lietu" Enberg

This is like arguing "hacker" is different from "cracker", might have been the case 30 years ago, definitely not so in the world we live in now. The security industry decided to find a new way to differentiate with the white/gray/black -hats.

I've worked in the industry quite a long time and never think a "Software Engineer" is in any way different from "Developer" when I see them in CVs/business cards/whatever. With the way people abuse the terms I barely see any difference between a "Junior Developer", "Developer", or "Senior Developer" .. hell some "Lead Developers" are basically people who learned to code 2 years ago on some online site and someone incompetent then hired them in their startup.

At least the difference between Developer, Architect, DevOps/SRE, etc. still mostly remains clear.

Collapse
carlillo profile image
Carlos Caballero

Hi Jeremy!

Thanks for your post.

I think that YAGNI and KISS are principles that you acquire with the experience because when you're novice you want to create complex software although your target was simple.

Collapse
leocolman profile image
Leonardo Colman Lopes

Adding to that, when you're starting you believe that complexity somehow decreases your chances for bugs, improves your code quality and things like that.

I believe that many times that's not necessary. And I believe that many senior developers don't grow out of that phase, and keep trying to apply ALL concepts and ALL abstractions ALL THE TIME!

Collapse
jeremycmorgan profile image
Jeremy Morgan Author

It becomes a giant feedback loop with some people. You create a bunch of complexity in the beginning, learn more and lean it down, then learn more and make it complex again trying to fit some neat pattern you read about. I've been guilty of it myself.

Sometimes you have to step back and ask yourself "Am I shipping anything? Why not?"

Collapse
ferueda profile image
Felipe Rueda

Awesome thank you so much, I'm just beginning my coding learning journey and this is really helpful!

Collapse
saisivanow profile image
SaiSivaNow

I know why we need to learn Software Design principles. They let you build scalable, maintainable, and reusable piece of code. There by generating more value to organisation by reducing computing or human resources required to do a Unit of Task which would convert as a value for you.

Collapse
mdhesari profile image
Mohammad Fazel

Very specific and out-standing, thank you. I'm on my way learning more about abstraction and OOP principles, if you have advance and good source code that shows these principles clearly, I'd be glad if you share it with me.

Collapse
jeremycmorgan profile image
Jeremy Morgan Author

I will be sharing a lot more examples of this an more in the coming few months on here. I imagine others will be joining in as well. Be sure to follow the Pluralsight page.

Collapse
codebrotha profile image
CodeBrotha

Do you really care exactly how an object is written to a database?

Oh, but I do care. lol

I get the point you're making though.

Collapse
kleene1 profile image
kleene1

Cool not sure on the extra code part ; I guess it's a case by case kind of thing.