At its core, software development is a knowledge-generation process. What happens when we think about what that really means?
There are many different perspectives on software development. Our perspective often depends upon our role and vantage point. Typically, developers are focused on code and architecture. Managers and team leads are focused on projects and personnel. For other roles, the process and product perspectives are primary.
There might not seem to be any problem with this multiplicity of perspectives. We get our work done, delivering value through software. However, many aspects of managing large, complex systems fall through the cracks because we don’t have a unified perspective. I want to offer one: I call it the knowledge activation perspective.
I’ll ease into an explanation through an example.
Imagine that you are on a development team of five people. One of your team members goes on vacation for several weeks. This vacation’s impact varies depending on how the team organizes its work. If people on the team practice pair or mob programming, there might not be too much impact. The knowledge of the existing system and the incoming work is shared across the team.
One of the most important initiatives in agile software development was finding practices that deal with what has been classically known as the bus factor. It addresses the question: how many people can a team lose without bringing the work to a standstill? Pair and mob programming are two ways of dealing with this problem, but there are many others: retrospectives, documentation, shared workspaces, and the list goes on. All of these practices work, but it’s worth considering whether we’ve looked carefully enough at the phenomenon behind the problem. Have we looked at knowledge in software development and developed a model of what it is and its qualities?
Knowledge as a thing
Very loosely, we can imagine knowledge to be a quantity. We may not be able to measure it, but we know a few things about it. One is that it deteriorates over time unless we take action.
Here’s a depiction of a team’s knowledge of a particular class in one of the services they are developing.
Notice there’s a quick ramp-up as the team writes the class and a much longer ramp-down afterward. The ramp down is simply due to memory. Over time we forget the details of that work. We move on to other things; maybe a team member leaves.
Let’s compare that diagram to this one:
Notice the extra bump on the right. This bump is the re-activation of that class. This bump happens when the team has to work on it, through refactoring or additional feature work that touches it. When we work on it, the amount of knowledge we have of that area increases. Knowledge around the class is activated.
There are a couple of ways of thinking about this process. One is that the team is rediscovering knowledge about the class. Another is that it is regenerating knowledge; I prefer this framing. We regenerate knowledge from the code and other system artifacts along with conversations among each other and investigation.
Again, we can’t precisely determine the amount of knowledge activated in this process, but it’s more than we had before we started working in that class. Close work activates and generates knowledge in socio-technical systems.
Qualities of active knowledge
When we take the concept of active knowledge seriously, we can see that it has a few qualities that affect how we can manage it and develop practice around it.
Active knowledge is generated in interaction with a system. We gain knowledge through reading or discussion, but working with it is the best way to understand something. Work engages parts of minds that reading and discussion don’t touch. It enhances memory and attention.
Knowledge fades over time. Our knowledge of the old work fades away when we move on to other work. Sometimes we have crystal clear memory, but essential details fade from our memory when we aren’t reminded of them in a work context. This fading happens at the individual level but also at the level of teams and organizations. If a person leaves a team, the part of the team’s active knowledge that person had is effectively gone if it wasn’t generated through shared work.
Knowledge can go stale. Active knowledge is accurate knowledge. If you worked in part of the system a week ago and people later make changes to it without your awareness, there is less active knowledge in the team. The knowledge you had has gone stale. Yes, some people on your team have a current understanding, but that understanding is not fully distributed in the team. Stale knowledge is problematic in an organization– people working with inaccurate information often duplicate efforts or change systems in counterproductive ways.
Knowledge can be more easily regenerated if artifacts are clear and understandable. Code, build scripts, and documentation are externalized knowledge. They are the parts that don’t live in our minds. It’s easy to overestimate the value of these artifacts. They are rarely complete and can become stale, but they often form the basis of knowledge regeneration. They are the things we go back to when we want to learn more.
Uncovered knowledge can enhance decision-making. Knowledge is activated whenever we work in a system. When we realize this, we can choose to work in different areas of a system to gain context and understand it more fully. Often the things we learn make us aware of the potential for new features or make us aware of easier ways of adding the features that we have planned.
When we look at all of these qualities together, the most important thing to realize is that knowledge management should not be focused on conservation and storage. Instead, it should focus on generation and flow. Over time, knowledge dissipates, and people move from place to place. We need to concentrate on developing practices that help us rapidly acquire and generate knowledge on-demand to support the valuable work that we do in systems.
Conclusion
There’s a lot more to say about Active Knowledge. My sense is that to the extent that we see knowledge as a real thing and speak about where it is growing or dissipating, we’ll arrive at better practices.
We’d love to hear your thoughts on this article and discuss the topic more. Click here to contact the author.
