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 imple... [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.

 

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

 
 
 

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

 
code of conduct - report abuse