My Favourite Principles in Software Engineering
I have been working as a Software Engineer for several years, and I have a different approach depending on the problem I face. I like to use some principles in software engineering that help me overcome most of these problems.
So, underneath I decided to share my favorite principles and I hope It can be useful to you. Enjoy the text.
Divide and Conquer
One of the most common approaches that can even be used in other contexts that Software engineering. It is simple to break a problem into small pieces then solve each part until you complete the big problem.
A scenario that is very normal to happen is when I have a regular expression. I start to match a small piece of text, then move forward to match another and so on until I match the whole piece I’m looking for.
Principle of good enough
Does WordPress fill the expectations of my team and the users?
By starting asking a simple question about the solution we can avoid going too far in any strategy we are planning.
Every day I see people complaining about that some technology is not good enough to perform such a job and should be something more trend or easy. But, It is important to remember about objectives and expectations on the product itself.
Pareto principle 80:20
For many events, roughly 80% of the effects come from 20% of the causes.
I like to take advantage of the 80:20 rule when I’m dealing with performance issues because I put my effort into that 20% that causes 80% of trouble in my application.
KISS
A new functionality came up and my brain starts to work out ways to solve this using a design pattern, tool, library, etc. Suddenly, I realize I’m over-engineering that solution instead of KEEP IT SIMPLE, STUPID.
Coding is a creative process and because of the many possibilities we have, It is very easy to lose ourselves in complex solutions. So, while you are planning how to develop the functionality try to think how far do you want to go in terms of complexity.
DRY
Don’t repeat yourself can help you to develop more abstract code avoiding duplications in your codebase.
I’m not saying to create big Utils classes, but It could be a good idea to create more specialized classes and modules.
Perfect is the enemy of good
Coding is one way to express my creativity and how smart I am. After finishing my job or my task, I want someone that reviews my code to feel pleasant about how perfect it is. But in real life, we have to meet a deadline that makes your code not always be perfect as you expect. More than perfect, It should be in production up and running without bugs.
Proof of concept (POC)
Proof of concept will lead you to understand and measure how tangible is to implement a feature or validate a technical capability of any implementation in your application.
Very common when I have a third party service to implement or integrate.
Rule of thumb
Trust in your workmates, since theory sometimes will not beat experience or practice. Some conditions are better to make use of the rule of thumb. Ask your colleague’s opinion when you get stuck in something that maybe someone has overcome in the past.
You aren’t gonna need it
Let’s add more related methods inside this class, someone could need one day. This is a legitimate true intention. However, good intentions are not always valuable for your project. I like to think when I need, I’ll include it. And the great news is, fewer tests to write, fast builds, and smaller files.
Easier to Change
By far my favorite principle. We get used to writing a code that should scale, be robust, and so on. Now, what if that amazing solution did not meet our expectations? Yes, you have to remove but sometimes is not easy as we think, so let’s leave it. (very common)
The next time you discover that library, package, or framework, try to answer if something goes wrong how easier it's to change? Just in case.
Remember, planning is half the job done, and using one or some of those principles would make your job a lot less stressful.
Thank you.
