This document is an attempt to compile a set of values which one can use as guiding principles when developing software at Minimum.

While we keep growing as a company it is imperative that we continue to ship robust, high quality code and it is the aim of this record to, at the very least, encourage additional reading and research.

Philosophical Principles

The following are some of the aspirational principles and practices that guide us:

  1. We value craftsmanship: code should be easy to read and understand, should be written with high attention to detail, and should be consistent in its style. Code is written for humans to read and maintain.
  2. We value resiliency: our system must be highly-available and stable. We must consider the implications of failures.
  3. We value accountability: we own and support our software, and are accountable for improving it, fixing issues, and learning from our mistakes.
  4. We value design and code review: review helps us maintain a high quality system architecture and high quality code, it also helps us to provide better feedback to our colleagues, learn to collaborate more effectively, and reduce the amount of mistakes.
  5. We value automated testing: automated testing allows us to iterate and more easily refactor our codebase, while verifying correctness and preventing regression.

Practical Principles

Don’t Repeat Yourself (DRY)

When writing your code, don’t repeat yourself. That is, avoid copy-pasting your code in different places. Otherwise, future maintenance will be difficult. The reason is that you will have to make changes to the coding in those various places.

Those changes will further necessitate changes in the tests to make the results click green. All of that will need more time, effort, and money.

To avoid such a pitfall, you can extract a common logic into functions. Additionally, if there are any manual works that you can automate, do so to keep your code lean.

Avoid Premature Optimization

Donald Knuth asserted that the root of all evil in programming is premature optimization.

We all agree that optimization speeds up the development process and reduce resource consumption. However, if you do it too early, it may backfire. The reason is that prioritizing a code is time-consuming and complicated if not done at the right stage. Additionally, when you are implementing the most optimal approach, software requirements may change. If that happens, your program ends up in a dustbin or become difficult to change.

Therefore, start with the easiest approach, even if it is not the most optimal. Then in the future, assess the chosen method in terms of resource and time consumption. Based on your assessment, you can move onto a faster algorithm that consumes fewer resources or efforts.

Chesterton’s Fence

A core component of making great decisions is understanding the rationale behind previous decisions. If we don’t understand how we got “here,” we run the risk of making things much worse.