Software development at an enterprise level can not be done by one individual as the software to design and maintain simply gets too big for one person to realize something in a decent amount of time. To handle larger projects multiple persons are required, this raises the challenge of organizing them in such a way that they are as efficient as possible.
Though it would be possible to have every individual work on it’s own part of code, this is not encouraged for two big reasons:
- A bus factor of 1 is a huge risk for any enterprise.
- Designing software from one point of view will often result in something that is less usable for other people/purposes.
This means that people are organized in teams to work on some code together, having shared ownership and responsibility for the maintenance of the code. But as team size increases, so does the overhead of keeping everybody up-to-date with the latest state of the software.
Shared knowledge can be done in multiple ways, which each its advantages and disadvantages.
- Writing good documentation: This can also be done if someone is working on some code alone to decrease the risk of the bus factor. While good documentation should be a requirement for every piece of software, it is often neglected or not kept up-to-date with the current state, making it completely useless.
- Code review: By letting someone else review your code, you decrease the chance of introducing bugs and errors, and at the same time gets your reviewer an idea of the state of the software. While this is a good idea, the reviewer should already have an understanding of the code, as the review is only focused on the changes, and not on the current state of all the code. Another problem with code reviews is that reviewing a big change is complicated, unclear and time-consuming. It requires a lot of willpower from the reviewer to do a good job.
- Team discussions: Whenever something structural or new is being developed, the entire team should get together to discuss the approach and design. While the other two solutions involved the team after the changes, this one does so before doing anything. It is obvious that this requires more time, as the entire team is busy working on the same thing, whereas this could have been done by just one person. The quality of the code will however often be better than in the other two situations.
There is no solutions that fixes all, in fact you will want to apply all three of them to achieve the best quality, both of the code itself as the solutions that is designed. Even in a team is it not feasible to have everyone work behind the same computer at the same thing all the time. People will have to work individually, but it is important that what they work on is being checked, approved and understood by the team.
Agile methodologies such as SCRUM focus on this a lot, by stating that the lowest block is the team and not the individual. In practice however I see that these methodologies are often used very loosely. Applying some practices of SCRUM, but forgetting about the team involvement. It is not enough to do the sprint planning as a team and then work on the issues individually, only to update the team of the changes after the facts.
This way of working is the opposite of what it should be. The team should first come together to discuss the problem, solution, design and everything else. Only after an individual should work on it, as the team has approved and agreed on the solution.