Most valuable software development principles

By Vladimir Khorikov

I’d like to wrap up the “Most valuable software development principles” article series with this post.

Most valuable software development principles

In this series, I tried to align the most valuable software development principles and order them by their significance. It is no doubt a highly opinionated task, so feel free to disregard this order. Nevertheless, I do think it reflects the actual state of affairs.

I believe the most important principle adhering to which can boost your productivity greatly is Yagni. If you’d ask me what is the single takeaway you could get from this post series, it is this: nothing can be done as quickly as doing nothing. Or, alternatively: the best code is the one that has never been written.

Always look for parts of your code base you can throw away or, even better, skip writing in the first place. Never try to anticipate the future, statistics says it is nearly impossible. Always cover only the bare minimum of the task you are about to solve, but do that really well.

The second most important principle is KISS. Simplicity is the key to building extensible and maintainable software projects. Always strive to solve a coding task in the simplest way that could possibly work. Remember, the simpler your solution is, the better you are as a software developer.

A simple solution is the one that:

  • Fully covers the problem,
  • Brings as little accidental complexity with it as possible.

If you have your colleagues saying “What? This is it?” referring to the code you’ve written, you can be sure you’ve achieved the goal.

I would say these two principles comprise 50% of success in any project and can be applied to any programming language and paradigm, be it functional or OO, so pay attention to them the most.

The following best practices cover tactics of how you should write the actual code:

  • Make sure you don’t expose the internals of your code base and properly encapsulate your entities.
  • Try to achieve low coupling and high cohesion in your code base on each level. Don’t fall into the trap of destructive decoupling, through. In most cases, it is as harmful as Big Ball of Mud.
  • Don’t repeat yourself, but at the same time, don’t confuse the DRY principle with code duplication. Remember, this principle is about domain knowledge, not the text on the screen.
  • Let your application fail fast. Always strive to shorten the feedback loop even if it means your software will feel less stable. With this technique in hand, such situation won’t last long anyway.
  • Try to always make your assumptions explicit in code. Agree upon conventions clearly, don’t allow misunderstanding affect your performance.

We are extremely good at pattern recognition. When you write code consciously applying the software development principles, you start seeing them everywhere. The more you do it, the better you become at making decisions and explaining those decisions to your colleagues.

The latter is as important as the former, especially in large teams. The ability to communicate the reasoning behind your gut feelings is vital when you work with other developers.

It is also important to set the groundwork and agree upon the basic principles you and your colleagues follow. It might be that decisions a colleague makes seem obscure or even plain wrong to you. This is a strong sign you don’t have the same set of principles in mind when you write code. Always strive to eliminate this disparity.

For example, a situation that happened to me quite frequently is misunderstanding concerning the fail fast principle. “This operation here may fail for a lot of reasons so you should wrap it with a try/catch block, just in case”. But after discussing the pros and cons of failing fast, we could agree upon some basic rules we should code by, and the misunderstanding went away completely.

The knowledge of the most valuable software development principles helps greatly with that. It is an indispensable tool when it comes to communicating your intent to others.

Other articles in the series


  • Gastón Kolocsar

    Hi Vladimir!

    In this post you say:
    “Try to archive high coupling and low cohesion in your code base on each level.”

    But in the Cohesion and Coupling difference you say:
    “Try to adhere to the “high cohesion and low coupling” guideline on all levels of your code base.”

    Is this intentional? If so, why?


    • Vladimir Khorikov

      Ah, sorry, I meant “Try to archive low coupling and high cohesion” of course.

      Thanks Gastón for your comment, nice catch!

      • Gastón Kolocsar

        Thank you for the good post!

  • Albert Capdevila

    Excellent article series, thanks!

    • Vladimir Khorikov

      Thank you! Glad you liked it.