-
Notifications
You must be signed in to change notification settings - Fork 0
Types of knowledge
Managing knowledge in software development is complex because the knowledge is fundamentally multidimensional. Classifying knowledge requires therefore multiple axes of analysis.
This is most likely an incomplete classification.
Knowledge stored in production code is static by nature.
The Object Oriented style of design uses objects and relations between objects to represent knowledge. Classes serve as a classification of objects, thus an optimization for managing multiple objects of similar types.
Knowledge is stored mostly in names and in lines of code expressing behavior. Ideally, reading the code should allow retrieving the knowledge stored there; however the flexibility of code, the main sale point of software, is also the biggest problem since the same behavior can be expressed in a clear or very convoluted manner.
Knowledge about things like expected usages of objects, user flows, or multi-step processes throughout an application cannot easily be stored in production code. Instead, we can use tests to store this knowledge.
It is the nature of knowledge to evolve in time. We cannot fight this, instead we need to embrace it and include it in our processes.
This may mean a few things. Perhaps the static representation of knowledge no longer represents the current state of our knowledge - what Ward Cunningham called technical debt. Perhaps we have learned how to express ourselves better in code. Perhaps we thought we knew too much and this led to inappropriate generalization and complexity. Or perhaps we were just plain wrong about some part of the knowledge and we need to remove it.
When we look through a codebase, we sometimes encounter architectural decisions that don't seem to make sense. One that I remember was a project that made extensive use of metaclasses and metaobjects, despite being used with very limited configurations that would have easily been expressed as normal objects.
It's useful to store knowledge about decisions for a later stage, so that when we encounter their effects we also understand the initial reasoning. It doesn't matter if that reasoning was correct or not, since most architectural decisions are made with limited information and affect many people for a long time.
Unfortunately, it isn't always clear which decision is important to document and which are not when making the decision. Other engineering disciplines deal with this problem through formal requirements and through engineering notes.