For some years ago when I was reading Andrew S. Tanenbaum’s ”Modern Operating Systems” this sentence caught my attention:  “Abstraction is the key to managing complexity”. I remember that I printed it out and pasted it behind my desktop with some other quotations! What is interesting about this sentence is the answer to another question: why are we using abstraction? Why are we using Object Oriented, Modeling and other abstraction-related techniques? The answer was obvious in Tanenbaums’s sentence: To avoid complexity! The reason for avoiding complexity: Simplicity is giving us confidence and saves our time and other resources (money, energy, etc.)! As Ray Ozzie (CTO, Microsoft Corporation) says:

“Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test.”

I believe details are one of the major sources of complexity and complexity is an exponential function of details. More details are resulting in much more complexity! Details are everywhere in our code. Isn’t possible to say that every if-clause is indicating a try to manage a detail and every programming’s loop is a try to reduce details by applying some common rules on objects!?

To understand how abstraction is helping to manage details we can use Uncle Bob (Robert C.Martin)’s description about Dependency Inversion Principle (DIP) in clean code:

 “In essence, the DIP says that our classes should depend upon abstraction, not on concerete details.”

Details are not just a problem in programming. They are an important issue in all of science fields and even everyday life! There are many techniques and methods about how to manage them and to remember them. Maybe our preconception about human races, people coming from a city or a province and men or women are because to get rid of all individual details about every different person!

In other words categorization like abstraction is another way to manage details. An important part of many sciences is categorization. To put phenomena and objects under same category is giving us the possibility to find details about them easier and to know how to act about/on them!

I think generalization (https://en.wikipedia.org/wiki/Generalization) is another known method to minimize details. Look at the definition of generalization from Wiktionary (http://en.wiktionary.org/wiki/generalisation):

  “The formulation of general concepts from specific instances by abstracting common properties.”

Actually maybe categorization and generalization are just two abstracting methods and it is not necessary to put them alongside abstraction as detail management techniques.

Unfortunately our techniques for eliminating details are very limited and our knowledge is being more and more complex by adding more details for every second. It is not possible to generalize every time because there are always exceptions.  One of the named advantages of functional programming is reducing side effects and I think these side effects are caused by details. But the functional programming never have been popular (At least the pure one) and I think the reason is that that is impossible to remove all side effects while programming. The reality is much different from pure abstraction. I like these sentences of Robert C.Martin in Clean Code:

“One might argue that a book about code is somehow behind the times—that code is no longer the issue; that we should be concerned about models and requirements instead. Indeed some have suggested that we are close to the end of code. That soon all code will be generated instead of written. That programmers simply won’t be needed because business people will generate programs from specifications. Nonsense! We will never be rid of code, because code represents the details of the requirements. At some level those details cannot be ignored or abstracted; they have to be specified. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code.”

I deeply agree with him. Programming? It is all about details.