How to Share Knowledge in Software Development

Over the years, we find that as many as 50% of software development projects fail. There are multiple challenges there, such as capacity, prioritizing, hiring, time management, etc. For developers, the main challenge is sharing knowledge according to the CodingSans State of Software development 2019.

In the report 24.57% of the respondents, up from 18.11% in 2018. says that. It surpassed even time management, hiring talents, and prioritizing development tasks. We also know that knowledge sharing is promoting innovation and developers' productivity.

What is knowledge sharing? Knowledge sharing is a systematic process for capturing critical knowledge from members of a team to share or distribute their knowledge and skills to the employees within an organization or project.

This topic will be even more important in the future, as more and more organizations will work remotely. So how we can tackle this, a very fundamental issue, and improve knowledge sharing in a team/project? There are a few effective methods of knowledge sharing:

Documenting

Technical documentation in software engineering includes all written documents created through the whole software development lifecycle. It exists to describe product functionality, unify all kinds of project information, and enable the exchange of communication between shareholders and developers.

We have different kinds of documents such as product requirement document, UX documentation, software architecture documentation, diagrams, QA documentation, product roadmaps, etc. All of these documents are usually stored in some kind of internal wikis/documentation tools, such as Atlassian Confluence, Sharepoint, GitHub, etc.

In general, we need to find a good balance between no documentation and excessive documentation, so only the most important information should be documented in one major place. It should represent a single source of truth. Also, documentation is an ongoing process and a team should update documentation or it will lose its value.

A good practice is to start with one central place in the project where all documentation will be stored, at the start of the project and organize it.

As this is a big topic, more on this subject will follow in one of the future blog posts.

Mentoring

While documenting knowledge is usually a passive activity, sharing is a more active one. Mentoring implies to have an instructor who will pass its knowledge to mentees. Mentoring is a strong technique to share knowledge, which is proven to be the most effective one, so it's very important, especially for junior developers to find a mentor when starting in a project. 

Mentor will help new members with onboarding to a project, but also with code reviews and introducing them to different kinds of hidden knowledge in the project source code.

Pair Programming

Pair programming is a very useful technique, that can be connected to the previous one, mentoring, where mentor and mentee can do a pair programming together. This technique helps new team members to get up to the speed in the project as well as to reduce the risk of errors when implementing critical code changes.

Mob programming is also a good way of transferring knowledge, where the whole team works on the same thing on the same computer. This technique usually helps in improving communication, having fewer meetings, and clearing a technical debt.

Knowledge Sharing Sessions

In knowledge sharing sessions, the team meets to share what they have learned. A session can be related to a specific topic, but also broader. It usually happens regularly, like once per sprint or month, as we want lessons learned to be still fresh in developers' minds. An important practice here is to record that session and store it into project documentation, so it can be used with new developers (if not outdated).

Another activity in this is tech talks. They can be unrelated to a project but can improve developers' knowledge and give an idea of how some topics can be improved in the project. Its usually good to be organized outside core development hours, such as after lunch.

Code Reviews

Code reviews help developers to learn a code base and improve their skills. It also improves code quality and reduces costs as we get fewer bugs.

However, we need to know how to do a good code review. Code review is usually based on a created pull request. We must have in mind a tone of the review that shouldn’t be harsh, as we can greatly influence morale within teams. More open-ended questions should be asked, as well as to be more empathetic. Nevertheless, important questions need to be addressed.

For new joiners, we use the same approach and quality bar, but we need to take special attention to a few first reviews, where we need to put an additional effort into a positive tone.

Writing Tests

Its widely known that tests represent a way of knowledge sharing. In tests we store a lot of knowledge about the system we make, that can be easily read and understand. This can be also easily visible when we take a look at QAs test cases or some test approaches such as Behavior Driven Development, where they use domain-specific language to write tests and different tools to store business knowledge (HipTest, Cucumber, SpecFlow, etc).

Some Less Good Practices

Even though it's important to have good communication in the team, communication tools (Slack, Teams, e-mails) are not usually a good way to store and share knowledge in the long term. They can be used only in the short term or to resolve some current issues. All the knowledge stored in those tools can be easily outdated or very hard to find after some time. Important knowledge from the communication tools should be documented in an appropriate place for it.

Another not so good practice are code comments, as it usually implies that the code itself is not self-documenting enough. Explaining the code with comments should only be done as the last option available. We should use code comments only if we need to document some counter-intuitive hack or bug fix which is not easily testable.

Conclusion

So, it's very important to have a knowledge-sharing strategy in an organization or a team. This strategy as its result should produce a framework for sharing knowledge. That framework would imply using all or some of the principles mentioned in this text, but also building up a knowledge base by creating a knowledge management portal or use tools such as Stack Overflow for Teams as a single source of truth.

We also shouldn’t forget that all of these activities of sharing knowledge builds trust and mutual respect within the team. During the time it will become more and more effective and new members will integrate more quickly into the team. In the end, the whole team will grow with every single of its members.

Thanks for reading this, if you have any inputs to this subject feel free to leave a comment or contact me directly.