What Are The Best Software Engineering Principles?

luminousmen on January 20, 2019

Software Development Principles — it is a number of specific rules and recommendations, which engineers need to be followed during program implemen... [Read Full]
markdown guide

And the most important: best practice is not a cargo-cult religion. SOLID, I am watching you.


As a person who spends a great deal of time evangelizing SOLID in particular, I totally agree.

Overly strict adherence to principles is just as bad as having no principles at all.


I agree that every developer should know these principles.

But it is at least as important to know that it is impossible to fully comply with all of these principles in practice. Especially when overdoing one of them, it is likely that you violate others.

One example: When applying DRY, you need to build abstractions, like moving the duplicate code to a function. This is fine to a certain extent but when you overdo it, the code will get harder to understand and violates the KISS principle.

Some of the principles are also highly subjective, for example SRP. During development, do you really know what a single resposibility is? Do you know which parts of the code are likely to change independently and which won't? Most of us are much worse than we think at predicting the future and that's where YAGNI comes from.

So in reality it is not that easy. Learning and obeying these principles will not automatically make you produce better code. You need to find a good compromise and that's much harder.


I agree with your comment completely. Even following Solid to the T can create overly complex code depending on the problem you're trying to solve, e.g. Business layer complemented with a repository layer and code bleed through.


Agree with all of them, but I would also add seperation of concerns as one of them.


Here is my contribution

  • Declaring "abstract" classes is completely useless.
  • Composition over inheritance everywhere. With this you don't have to worry about Liskov principle, Cohesion.
  • Class is a bad word to build a communicating object. It should be named Cell. Assume that way.

Many more, but time is up for now.


This is a fantastic list... I'm going to print it out and put it up in my cubicle when I get to work in the morning. <3


Thank you that means a lot


Not really a fan of big upfront design. I prefer a "just enough" upfront design approach to get started, and then design as the need to do so arises. A big upfront design has the tendency of making future changes difficult, and "change" is the one constant in software development.

Regarding all the other principles, I have the same opinion as Frank Puffer a few comments above: you should know the principles and adhere to them, but you have to strive for that sweet spot of balance between them.


I find "just enough" design + SOLID leads me to code that does what it needs to, but the abstractions are clean enough that there are enough places for me to expand some part to deal with changes (more likely more details) to the specifications


Zero upfront design here.

Covering following roles does the job.

  • Interface class
  • A Machinery Object (a do'er)
  • A Consumable Object (e.g. input)
  • An InterActor Object (e.g. adapter, handler)

All class properties private, no getter-setter and other magic tricks.

Code of Conduct Report abuse