Need for Docs

The title of this post is a bit mystifying and I am sure you all are wondering what this post is all about! He he.. Let me tell you a story..

But before that have a look at the following definitions (that are taken from wikipedia) …

1.Tacit Knowledge

By definition, tacit knowledge is knowledge that people carry in their minds and is, therefore, difficult to access. Often, people are not aware of the knowledge they possess or how it can be valuable to others. Tacit knowledge is considered more valuable because it provides context for people, places, ideas, and experiences. Effective transfer of tacit knowledge generally requires extensive personal contact and trust. Tacit knowledge is not easily shared. One of Polanyi’s famous aphorisms is: “We know more than we can tell.” Tacit knowledge consists often of habits and culture that we do not recognize in ourselves. In the field of knowledge management the concept of tacit knowledge refers to a knowledge which is only known by an individual and that is difficult to communicate to the rest of an organization. Knowledge that is easy to communicate is called explicit knowledge. The process of transforming tacit knowledge into explicit knowledge is known as codification or articulation.

2. Codified / explicit Knowledge

Explicit knowledge is knowledge that has been articulated, documented, and stored in certain media. It can be readily transmitted to others. The most common forms of explicit knowledge are manuals, documents and procedures.

Now let’s start the story..

Once upon a time there were two software firms (A and B). Both started at the same time and let’s say both have hired 10 fresh graduates and have project managers and other managerial people. Then soon after their starting, both of them got some cool projects on e-governance. Time passed by.. They got some other projects on e-governance and were busy with those projects. And in this way five years passed and in those five years A and B both worked only in the e-governance sector. Consequently they got some reputation in the industry as e-governance specialist. In due course, both of the companies have got new deals – new projects on e-governance. Both of the projects have quite same requirements.

For the sake of the story, let’s say A has all the experience in tacit form whereas B has it in coded form and A and B hired some new people for their new big projects. Now A will find it difficult to transmit its experience to the newcomers. Also in the last 5 years A did not form any kind of strict process or policies (on each and every part of the development cycle), people in A mostly rely on their personal abilities and experiences rather than a shared mechanism of doing and solving a particular problem. As well as, they did not build well documented reusable libraries. So, for the new project they have to give some more time to transfer their experiences to the new people. As a result, A will take a longer time to develop the new software and also the cost will be high.

On the other hand, B has developed..

• a large collection of well documented libraries and reusable objects,
• a well defined process of gathering the requirements (may be template that suits best for e-governance)
• suitable architectures and design patterns (of course documented) for building e-governance applications.
• some other quite strict policies, processes and standards

So for B ..

• it will take less time to build the new app.
• It will take less time to transfer their experience to new people.
• The quality of the software will be higher (as those reusable objects are well tested and etc)
• The productivity and efficiency of the team will be higher.
• Cost will decrease.
• Rework will be less.
• Customer satisfaction will be higher.
• And most importantly now they can pay more!

So, we can see documentation and articulation has a role to play. Managers should encourage these things and team should practice knowledge management. And it is very likely that in the long run these things will pay off as the ability of making more profit of the company should go higher with the experience.

The story is not finished yet… now those 10 experience people of company A has left the team. Now what will happen? Things will be much worse; company A now has nothing but a disc full of codes of their previous projects, New people will not like to dig into those codes and even if they like it will take a quite a bit of time. And still company A will be fully hopeless losing all of its experiences that flew away with the brain of the older developers. This impact (because of the switching of developers) is known as turn over impact. When a developer of a company like A, leaves like that he is not only leaving with the knowledge but also leaving some liabilities to the company

Now if the same thing happens to the company B (most unlikely though, as they are paying higher) the impact will be much less. The new people will be able to adopt things quickly and the company will survive and will still grow..

So writing documents..

• is not because of only understanding the problem (some problems are small enough and some people are smart enough to skip the documentation)
• it is because we want coded knowledge that can be shared amongst others
• it is because it helps the company to grow and earn more revenue in the long run
• it is because it is the capital of the company that it will gain over time
• and it is because cash can be extracted from this intellectual capital.

It is all about capturing, documenting and articulating tacit knowledge.

Still not convinced? Just think how a little code convention document helps to standardize the code and how every developer gets benefited from it.

To know more about knowledge management go to this link http://www.cio.com/article/40343