Keep It Complex and Kludgy

KICK is my brand new backronym for "keep it complex and kludgy". It is related to Macco's razor, which holds that the weirder and more obscure answer is always the correct answer.

This seems to be the main ground rule for way too many self-appointed systems architects I've met over the years. I'm about to unveil this advanced guiding principle which will boost your design skills, turning you in a real professional.

The KICK principle states that you should design every system as complex as you are able to (not that you need to understand it). This way you will make sure nobody could comprehend it whatsoever. The goal of this philosophy is to become irreplaceable in the context of the project. A disciplined and tenacious work will make you an essential part of your organization!

In order to achieve this objectives, there are a number of well-known techniques at your disposal:

• Class explosion: follow the wise aphorism "the more, the merrier". Why would you be satisfied with 50 classes, when you can have 500 of them? They don't need to perform any task in particular. For example, you can let the classes forward every method's invocation to another object. This technique does not only work with classes: you can let a whole bunch of functions massage the data, on and off, without doing anything at all.
  
• Namespaces abuse: you need to get your project's namespace all tangled up, until there is no remaining logic on it. Namespaces must be nested ad nauseam. You might find useful:
  • Repeated names here and there
  • Similar names that differ only in a single letter
  • Names that are mostly compound of numbers
  Since this technique can be repeatedly applied back and forth, you must keep on until nobody could possibly find any file.
• Leaky abstractions: whenever you provide an abstraction to a higher level, you should always slip some specific implementation's details which have to be handled by your client in a way that it would really feel more comfortable to work directly low-level than through your leaky abstraction.
• Counter-documentation: the key is to write the opposite of what things really do. Documents are write-once: you cannot update them as the requirements change. This applies not only to formal documentation, but the code itself. For example, the name of a function which reads a file should be writeObject.
  
• Transvestite patterns: Everybody groks the Gang of Four book. You can take advantage of this fact by masquerading one design pattern as something else. For example, you can create a class FooSingleton, whose getInstance method always creates a new instance. Of course, don't forget to provide a public constructor, so nobody can picture out which is the proper way to use it.