Useful Little Things

In his book Software as Capital, Howard Baetjer comments…

Because software, like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process.  The process is a dialogue in which the knowledge that must become the software is brought together and embodied in the software.”

Baetjer goes on to describe how software evolves, through iterations, as more and more useful knowledge is added.

This process has a great deal in common with hiring and cultivating a new employee in a large organization.  Initially, the new employee can be seen as an empty vessel to be filled with knowledge.  On the first day of work, we add fundamental knowledge, such as where the break room and bathrooms are located.  In the weeks that follow, the new employee learns about culture and how we, as a company, do things.  As weeks turn into months, the new employee learns our business processes, becomes “functional” and can begin to provide some small return on the investment we have made.  Finally, as months turn into years, our employee transforms into a valuable resources that more recent hires turn to as a mentor.

The larger the organization, the more specialized our employee will become.  If fact, many employees of just a few years will quickly surpass in knowledge employees with decades of experience, due to a tendency towards specialization.

Now, back to software…

Software behaves in the same way.  In the first days (or weeks) or development, we define its scope and requirements.  In the months (or years) that follow, we construct, test, and deploy the software, entering a cycle of continual enhancement and improvement.  Eventually, the software embodies the sum of knowledge in its area of specialization, surpassing the masters that taught it.

Herein, lies a problem very similar to one faced by Human Resources.  What to do when the software (employee) falls from favor and must be replaced.  How do we extract that body of knowledge?  Where do we put it?  How much knowledge will be lost?

Software, like most long term employees, cannot simply hand you the sum of their knowledge and experiences.  Many times an employee simply knows the answer without understanding the how they know it.  And anyone who has worked on a rewrite of software understands that, although the code embodies the knowledge, the knowledge cannot be obtained by reading the code.

How do you think the knowledge capital of software can be extracted and retained for future generations?