Skip to main content

Theory or Practice ?

As a practicing Project Manager in the software industry, the majority of the people i come across can be divided into two categories.

The first is the set of people who don't read books or papers or manuals on software engineering or project management.  For them, everything that has to be learnt can be learnt by doing and they dont find much of a point in learning from other people's experience. For them it is all simply 'theory'. These set of people don't for a minute think that most of what is written in books and papers comes out of practical experiences of people.

The other category of people always want to refer to the manual first. They do this, even when there is an urgent or pressing issue. For these people, what is written in the book or in a published paper is more important than the present situation. The assumption is that solutions to all problems are already available some where and they will find it by reading books or manuals.

The unfortunate part is that neither of these set of people are right. Why is that ?

For us to understand why, we need to understand how the human brain learns. A little bit of evolution before that.

How did human beings come to a staggering 7 billion strong and growing from a small number (some scientists think this population to be not larger than 2000).? Scientists attempt to explain this progress using a theory called Variability Selection Theory.  According to this theory, human beings evolved by giving up on stability and by adapting to variation itself.

Variability Selection Theory predicts some simple things about human learning. It predicts that there will be interactions between two powerful features of the brain.
  • A part where we store what we learn. (You can equate this to a database)
  • the ability to make use of or (improvise off) that database. (You can imagine this to be a set of rules).
The database allows us to know when we have made mistakes. The ability to improvise allows us to learn from the mistakes. Both of the above gives us the ability to add new information under rapidly changing circumstance.

To put it in a pictorial representation, it looks some thing like this.


From the diagram it is obvious that one feeds into the other, thereby enriching both.

People who emphasize on either Theory or Practice don't have the advantage of the typical relationship that feeds from one to another and enriches both.

This results in the People who emphasize theory or a stable rote learned database to ignore the improvisatory instincts drilled into us for millions of years, resulting in less creativity and monotony.

People who emphasize practice also suffer because these don't have the experience database in the first place. These people typically ignore the need to obtain a deep understanding of a subject, which includes memorizing and storing a richly structured database.

Any person who underlines a work environment  that stresses only the database instincts ( theory) or only the improvisatory instinct ( practice) ignores one half of the brain altogether. The person or the environment is doomed to fail.

For a person who understands the points given above, the database and the set of rules, increase in size over a period of time, as the person learns. This helps the person to approach the problem that he/she faces in an unique manner and stand out from the crowd.

To conclude on the query that we started with, "Theory or Practice?", i would say "Theory and Practice".

Thanks to the book 'Brain Rules' for the interesting piece on human learning. you can expect more from the book in the coming days.

Comments

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …