For all of you that  know and love KISS, let me introduce you the KISS FACT.

Keep it simple and short. Focused and clean too.

If you get it right, you will say that FACT is somehow implicit in KISS. Nonetheless, it is very important to mark these concepts strong in their own word because people tend to forget about them.


Any software is made up of two kinds of code working together:

  1. Business code: The code that does the actual things that define your application.
  2. Architectural code: The code that you need to make the first one work.

As a rule of thumb, the less architectural code you write the better, because:

  1. You should spend most of your time creating value. It is the real reason you are being paid for, to make the product owner happy... and hopefully your users too.
  2. Almost every architectural needs you have is fulfilled by some library out there that has been written to help you focus on your business code.

"Focused code" means that the architectural code is short and concise, and very easy to understand what it does and also how it works, and why is there.

In most of the cases, the architectural part of a focused code should look more like glue code than like a framework.

Whether  you are writing a great deal of architectural code, or it is complex enough to make it hard to understand, it seems that you should be splitting it as an external library or framework. That way, anyone who needs to work with your  business code does not have to read and understand this big and complicated architectural code but just the documentation of the external library you wrote instead.


Code evolves. One day you are writing some helpful function, and the next one you are not using it anymore.

Please, please, please, please.

  1. Do not just comment stuff out.
  2. Do not keep them around just in case you need it in the future.
  3. Remove all the unused code once and for all, and as soon as possible.  

You can save these snippets and helpers outside your working code, to prevent them from getting in the way.

That's all about what the FACT is. But why should we mind it?

  1. To keep your code readable and maintainable.
  2. To help you deliver more value to your users.
  3. To make the onboarding of new developers easy.
  4. To prevent you from bugs and vulnerabilities.

Keep it simple and short. Focused and clean too.