Wednesday, October 26, 2011

When the philosopher meets the software engineer

I know my readers will be jumping out of their PC-s or laptops or thinking about switching over to any other links in their blackberries after they read the title of this article. What in the World, they will think, this guy is talking about? Philosophy has got something in common with Software Engineering after all? Is not Philosophy a boring, dull, time-killing thing for ripe, old men with big, white beards? And is not software engineering a thing for cool dude, millennial-s? But there is something that binds philosophy with software engineering. Well to describe it in one single word is “reductionism.”

Let me explain the term a bit more. When we want to do a task, from the simplest of the tasks which includes doing shopping in our neighborhood grocery stores or even say eating our lunches with our hands or to the most extreme like sending a man to the moon, we tend to break our whole big job part into small tasks i.e. we reduce our overall objective into small goals which we can do with ease and after we are able to perform all those small goals we can say that the whole task is done. That is in essence the core concept of “reductionism”. This particular method follows one of the earliest truths of problem solving: it is always easy to solve a complex problem by breaking it into separate parts and then solving those parts individually.

The “reductionism” is considered one of the oldest and most common methods through which mankind has started to solve its various problems from finding out how the world works out to running and managing a project successfully. When Philosophers try to find out the answer of a particular question or the scientists try to explain a thing what they tend to do is to divide it in smallest possible parts, then explain away the smallest part and afterwards try to explain similar parts in the same way, and then combine all the parts together to come out with the overall theory. Say for example if I say that all human beings die after 60. Now to explain let me say John died at 65, Ramesh died at 61, Rahim died at 75, Ariel died at 71 and Novjyot died at 77. Now all my sample persons die after they have been alive for a minimum of 60 years on the earth. So based upon all of my samples, I can conclude my earlier claim that all human beings die after 60.

Even in our software projects, we tend to follow the same way. In any of our project strategies and project plans, we tend to divide the whole project execution into four basic parts:

1. What are we going to do (objective of the project)
2. How we are going to do it (approach for the project)
3. When are we going to do it (estimations and timelines for the project)
4. Who amongst us are going to do what (team role definitions and team structures)

Once we are through achieving all these parts then the overall project goes smooth and focused and if even one of the parts is not properly addressed then the whole project can go for toss.

Reductionism is not only in the realm of the philosophers and scientists but it is widely used in political and strategic fields also. One of the major strategies of the Roman Empire used to be “divide et impera”(divide and rule) i.e. divide your enemies into separate camps thereby weakening them and then they are easily conquerable. This strategy says that if you have an enemy to conquer and the enemy is most difficult to conquer then first try to create confusion and division within the enemy camp and then once you are successful in dividing the enemy camp then you can easily conquer them.

Even in literature and popular fictions we can see many examples of the same techniques of reductionism. Do you remember that Eeshop’s fable from your childhood whereby a dying farmer asked his sons to first break some sticks one by one and then asking them to break those sticks after putting them together? That story meant that reductionism inside families and society can ruin the whole thing.

So as we can see now more and more how common we cool, hip, software engineers are in our approach to finding solutions to our problems to the philosopher with a bored face and bearded chicks as well as a politician with sharp brains and crooked hearts. So reductionism i.e. solving problems by breaking it into parts is the way through which we cool , hip software engineers are attached with the bearded , boorish philosophers.

No comments:

Post a Comment