Unnecessary Complexity.

Publicated on : 1192954750
Dealing with complexity is an inefficient and unnecessary waste of time, attention and mental energy. There is never any justification for things being complex when they could be simple. -- Edward de Bono.

Companies like to think that if their product is complex, and contains a lot of features, they will be in a better position than the competition. They featurize their product to overwhelm the customer. More is what we are used to get, so more they give us, and more we demand. Programmers on their term, usually start programming without a clear path. Making things enormously over-complex than it has to be. Quite often they don't envisage the system in their mind, but start programming blocks of software, and attach them together to make it work. Basically they are constructing a system that contains parts, like an automobile. Parts will fail and break off. I like to show you another way of getting at the same point quicker and more secure. A path that is clear and easy to understand. This path is called the baseline method, and is actually based upon organic growth. Just like the human body. It is an organism that grows, and is not slammed together like a machine. So there is a fundamental difference between a mechanism and a organism. They are not the same.

Anyone keen in maths knows that nature can create complex structures through simple forms, but it starts out with simple paths, not complex ones. Complexity if done correctly and in the right terms, can be a result of simplicity. Not the other way around. But such complexity is still a singular form of simplicity that works together instead of against itself. So we can create a complex system that is in fact programmed simply! You can create software that has a ton of features, but only have limited lines of code.

The baseline method is used to design a system that takes away unnecessary complexity by following a simple path. A path of least resistance, the way of nature. You could make a lot of turns to get at the same destination, but anyone in logistics knows that careful planning leads to time saving and gets the product on time at the customer. There is no reason why you should make an extra 100 miles if you don't have too. This is the same in programming and ultimately leads to better security if steps are simplified. So again, we think in terms of logistics, how do we get 3 products to 3 customers without losing too much time? exactly, we plan a route. When planning code architecture first you'll have to decide what the program is supposed to do, and stick to that. Ignore features, and go straight for functionality. There are two ways, one is to reduce complexity afterwards, or following the baseline method, which intuitively goes like this: We first design a system, making it as simple as possible and then start programming the software.

By avoiding extra routes we ensure