7 Software Development Principles That Should Be Embraced Daily

Being a good programmer is a mix of skills and some common sense. It is all about being pragmatic and knowing what is the solution that fits better your problem. When facing a challenge, there are some software principles that will guide you in choosing the most correct approach.

Those are a set of guidelines every developer should know and revisit from time to time. Think about them as your secret sauce when programming.
Consistently applying those principles will make your transition from mid to senior software engineer easier. You may find out that (probably) you are applying some of them intuitively.
There are a lot of principles. We will just focus on the seven most important ones. Embracing these will help you improve and become a better programmer.

1. You Aren’t Gonna Need It — YAGNI

It’s simple and self-explanatory — but not everybody follows it. When adding code, make sure it’s needed right away. Don’t leave code hanging because you think it might be useful later on.

This applies when doing refactoring. If you refactor a method/class/file, you shouldn’t be reluctant to remove any methods that are left hanging. Even if they were useful in the past — they are not anymore.

A day may come when they are needed again, and you can use the git repository to bring them back from the dead.

2. Don’t Repeat Yourself — DRY

This concept was first formulated by Andy Hunt and Dave Thomas’s book The Pragmatic Programmer: From Journeyman to Master.
The idea revolves around having a single source of truth. What is that anyway?

“In information systems design and theory, single source of truth (SSOT) is the practice of structuring information models and associated data schema such that every data element is mastered (or edited) in only one place. … SSOT systems provide data that are authentic, relevant, and referable.”
— Wikipedia

Keeping a single source of truth will help have a more solid and more self-explanatory codebase.
Having duplicated code is a waste. You will have to maintain the same logic in two places, do the tests in two places, and when one place changes, you will have to remember to change the other one.
Most of the time, code duplication comes from a lack of knowledge of the system. Before coding anything, be pragmatic: have a look around. Maybe the feature was implemented somewhere else. Maybe that business logic already exists somewhere else. Reusing code is always a smart choice.

3. Keep It Simple, Stupid — KISS

This design principle is a design principle noted by the U.S. Navy back in 1960. This principle states that simpler systems will work best and more reliably.
You can find many similarities when this principle and reinventing the wheel, which takes back in the 1970s. It was used as a business and advertising metaphor.

Applied to software development, it means exactly that — don’t overengineer. Sometimes the smartest solution is the easiest one. Building performant and efficient code with simplicity is beautiful.
Nowadays, one of the most common errors is to try to use the new tools just because they are shiny. Developers shouldn’t be motivated to use the latest tech just because they are new — but because they are right for the job.

4. Big Design Up Front

This software development approach is crucial — and many times ignored. Before jumping into the implementation part, make sure it’s all well thought out.

“Many times, thinking things out in advance saved us serious development headaches later on. … Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.”

— Joel Spolsky

Many developers feel that they are not making progress if they haven’t started to code. That is wrong. By drawing a specific plan you are saving yourself from possibly having to start from zero again.
Sometimes, other people need to be involved in the flaws of a design. The sooner those conversations happen, the better for everybody.

A very common counter-argument is that the cost of fixing issues is lower than the time it takes to plan them. That is certainly not true. The fewer bugs/inconsistencies your user is facing, the better their experience will be. You might not have another chance to get hold of them.

5. SOLID

It’s the most well-known software principle. Solid is an acronym for:

S) Single-responsibility principle

Its importance cannot be overstated. Every object, class, and method needs to have a single responsibility. If your objects/class/methods are doing too much, you will end up with the well-known spaghetti code. Here is an example:

This method looks harmless but it is doing too much:
saving the object in the BE
taking care of the UI notification
some navigation
Another side-effect is testing. It is harder to test entangled functionality.

O) Open–closed principle

Software entities should be open for extension but closed for modification. I mean, we shouldn’t override methods/classes just by adding more functionality as we need it.
Inheritance is a good way to go about it. In JavaScript, this is mostly done by composition.

💁 A rule of thumb: If you modify an entity to make it extensible — you failed that principle the first time.

L) Liskov substitution principle

This principle says that objects of a superclass must be replaceable with objects of their subclasses, and the application should still work as expected.

I) Interface segregation principle

This principle was defined by Robert C. Martin while consulting for Xerox, and it’s an obvious one.

The software should be split into multiple independents parts. Side-effects should be reduced as much as possible to ensure independence.
Make sure that you are not forcing objects to implement methods they will never need.

D) Dependency inversion principle

This principle cannot be overstated enough. We should rely on abstractions, not on concrete implementations. The software should have low coupling and high cohesion.

You shouldn’t care about how things are built — but about how they work. One easy example is when using dates in JavaScript. You can build your own abstraction layer. That way, if you ever change the Date provider, you will only have one place to change and not a thousand.

Sometimes, building that abstraction layer takes some effort, but it does pay off in the long run.
As an example check date-io, it creates that abstraction layer that enables you to use it with multiple Date vendors.

6. Avoid Premature Optimization

Premature optimization is the practice that encourages developers to perform unnecessary optimization before it’s proven that it is needed. I think if you apply KISS and YAGNI you shouldn’t fall for this.

Don’t get me wrong, it’s good to try to anticipate that something bad is going to happen, but before going into the implementation details you need to check that those optimizations are really useful.

A very easy example is scaling. You are not going to buy 40 servers because you think your new app is going to be viral. What you will do, instead, is add servers as you need them.
Premature optimization can lead to delays in your code and, therefore, increases the cost of time to market features.
Many know premature optimization as the root of all evil.

7. Occam’s Razor

“Occam’s razor, Ockham’s razor, Ocham’s razor (Latin: novacula Occami), or law of parsimony (Latin: lex parsimoniae) is the problem-solving principle that “entities should not be multiplied without necessity”, or more simply, the simplest explanation is usually the right one.”

-Wikipedia

What does it mean in the programming world? Don’t create unnecessary entities without them being needed. Be pragmatic — think if those are needed as they might end up increasing the complexity of your codebase.

Conclusion

These principles are not very complicated. In fact, their simplicity is what makes them so beautiful. If you are overwhelmed, don’t be. For now, just try to increase your awareness, and try to include them one at a time in your daily routine.

Having some basic — but powerful — principles to stick to will help you become a better programmer and have a clearer idea of why you are doing things.

If you are applying most of them intuitively it’s good to have that aha moment where you see why you were doing things in a certain way.

More programming content will be coming your way soon.
Cheers.