This post is a part of How To Ship Maintainable Product series

The problem with the people

Almost every software product is built by humans. A small amount is generated. Humans are the most unpredictable factor - we are like that by definition.

To build a maintainable product we should isolate unpredictability as much as possible. That includes people too.

There is a famous “hit by bus factor” measurement claiming that: if because of one person the whole process of development is stopped (because he was hit by a bus) then there is something wrong on the organisational level.

Another unpredictable event may occur if the key developer suddenly leaves the company. Usually, the development process suffers later on for a while.

Unpredictability is something that may happen. We can not know about it, but we can mitigate its impact.

Knowledge must stay with the product

Having in mind the arguments given above we should prepare such a framework, that will protect us against them.

Coding standards

Every software product should have its own coding standards defined upfront. Set of rules that are followed during development. Engineers should program according to those rules. This will provide more consistency in a project. Naming, syntax, code and files structure - following one defined standard makes it easier to understand.

Cross project development

Rotate teams. Developers are smart and if they know that the code is rotated, they will try to leave it in better shape. Code polished by multiple developers is better understood.

Pair programming

If a company is small and there are just a few developers it’s not possible to do cross-project development. Pair programming is another great technique. This technique requires some self-awareness from a developer in terms of I can also make a mistake, I'm just a human. There is no room here for rock stars who don’t like to collaborate and share knowledge.

What we gain is more standardized code. The structure, syntax, naming convention, ways of solving similar problems - all that will look similar. Products following strict rules have more predictable structure.

Example

If you look at open source projects you would see a tendency in a way the code is written and the product developed. Usually, an OSS project applies well-known practices. It uses KISS principle on a higher level. It should be easy for a new volunteer to start contributing as easy as possible. The project is prepared for that… or should be :)

Conclusions

In order to mitigate human factor from software development, we should make the code a shared resource maintained by a whole organization. Delegate responsibility for sharing knowledge with the developers, so they feel confident to continue to develop even after bus factor incident occurs.