Over the years, we find that as many as 50% of software development projects fails. 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 actually promoting innovation and developers productivity.

What is actually 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, 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 kind of project information and enable 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: Attlasian Confluence, Sharepoint, GitHub, etc.

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

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

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 more active one. Mentoring implies to have an instructor who will pass its knowledge to mentees. Mentoring is a strong technique to share a knowledge, which is proven to be the most effective one, so its 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 a hidden knowledge in the project source code.

Pair programming

Pair programming is very usefully technique, that can be connected to the previous one, mentoring, where mentor and mentee can do a pair programming together. This technique help 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 less meetings and clearing a technical debt.

Knowledge sharing sessions

In knowledge sharing sessions, team meet to share what they have learn. 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 mind. An important practice here is to record those session and store it into a project documentation, so it can be used with new developers (if not outdated).

Another activity in this are are tech talks. They can be unrelated to a project, but can improve developers knowledge and give an idea 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 a code quality and reduce costs as we get less 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 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 make special attention on a few first reviews, where we need to put an additional effort with positive tone.

Writing tests

Its widely known that tests represent way of knowledge sharing. In tests we actually store a lot of knowledge about the system we make, that can be easily read and understanded. 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 se use domain-specific language to write tests and different tools to store business knowledge (HipTest, Cucumber, SpecFlow, etc).

Some less good practices

Even though its important to have a good communication in the team, communication tools (slack, teams, e-mails) are not usually a good way to store and share knowledge in a long term. They can be used only in 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 imply 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 bux fix which is not easily testable.

Conclusion

So, its very important 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 single source of truth.

We also shouldn’t not forget that all of these activities of sharing knowledge builds trust and mutual respect withing 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.

Stay good!