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 respondents said so, up from 18.11% in 2018. It surpassed even time management, hiring talent and prioritizing development tasks. We also know that knowledge sharing promotes innovation and developer 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 stakeholders 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 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 an ongoing process and a team should keep it updated 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 means having an instructor who passes their knowledge to mentees. Mentoring is a strong technique to share a knowledge, which is proven to be the most effective one, so it is very important, especially for junior developers to find a mentor when starting in a project. The 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 a very useful technique, and it connects to the previous one, mentoring, where mentor and mentee can do a pair programming together. This technique helps new team members get up to 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, teams meet 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 mind. An important practice here is to record those sessions and store them in the project documentation, so it can be used with new developers (if not outdated).
Another activity in this area 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. They are usually best 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 keep in mind the tone of the review, which shouldn’t be harsh, as it greatly influences morale within teams. More open-ended questions should be asked, and the reviewer should 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 pay special attention to the first few reviews, where we need to put an additional effort with positive tone.
Writing tests
It is widely known that tests represent a way of knowledge sharing. In tests we actually store a lot of knowledge about the system we make, that can be easily read and understood. This is also easily visible when we take a look at QA test cases or some test approaches such as Behavior Driven Development, where we 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 is 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 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 they 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 bug fix which is not easily testable.
Conclusion
So, it is 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 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. Over 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 one of its members.
Thanks for reading this, if you have any input on this subject feel free to contact me directly.
Stay good!