Optimised team work

With the right processes and tooling, it becomes a lot easier to share code between developers. With the right amount of documentation in the right place, you also flatten the learning curve for onboarding developers to get up to speed. This reduces the risk that responsibility lies with a single developer (read: a single point of failure) and encourages developers to share, contribute, review and refactor code. Just make sure you have ample coverage so that you confidently can refactor, with minimal impact on existing features.

Any software project tends to grow in complexity over time. Without a good development strategy, sooner of later the quality of projects can erode.

Several problems can contribute to throwing more money at the problem: code isn't efficiently reused, accidentally overwritten or is simply not findable in the codebase. With ad hoc patches the codebase grows but not always in the right direction. There's also the risk where specific knowledge is distributed between a small number of developers.

Now you have a problem. The project has become increasingly unpredictable and unmanageable.

Luckily, there are a couple of measure you can take to maintain the quality of a project and make it readable, scalable and manageable. These also ensure that developers can continue working in a guided way and can support each other better.

These measures affect different areas and are intwined in the development proces. These are applicable to any software project and I want to stress that the implementation should be the teams responsibility. The intrinsic motivation ensures the longevity of the guidelines that are set out. I would suggest to plan a couple of sessions to discuss the plan of approach and how to implement, but also ensure reoccurring review sessions on the process, just to ensure a level of quality. Keep in mind that guidelines are not set in stone and can be revisioned if the need arises: what makes doesn't make sense now maybe does make sense when the environment changes.

Branching and version control

This should be an obvious topic for any project. Still, a badly implemented strategy could cause a lot of friction. There are several strategies here that could work, so I would encourage you to discuss and choose and define one that fits the way the team wants to work. On, for instance, Atlassian.com you can find a decent example of different methodologies.

Style guides and code guides

To keep code readable and consistent you can make agreements. Even better would be to make those agreements an automated and integrated part of writing code. Drafting a style and code guide once saves a lot of discussion and personal interpretation down the line.

Structure

Software almost always consists of multiple source files that form the application. By using a clear folder structure and naming conventions on files and folders, it becomes much clearer what a particular piece is responsible for. Frameworks can help, because they usually already have a preset, or provide documentation on a preferred convention.

Culture

This part is vital, because software is by default not set in stone. It is prone to updates, refactors, expansion of contraction of the code that sums up the application. By having a clear definition on how to approach changes in environment or software (with the above rules you should be good), you can facilitate a culture which remains critical on the right way to approach things. The culture should encourage the sharing of code where people can be critical on each others' quality, but not judgemental. Every team should have plenty of time and budget to communicate.

Future proofing

With the right processes and tools is becomes so much easier to share code and responsibility between an entire team rather than a single person. It also eases the learning curve for new developers onboarding a team. On top of that it encourages a transparency culture, where people are willing to share, review and refactor code when needed. The transparency translates to better predictability, which is a nice bonus for stakeholders outside of the team.

These points should give some idea on areas to focus on when establishing a way of working within teams.