Maintaining the code

Git, Pull Requests, Quality, Workflows, Four-Eye-Principle, Prettify

As mentioned in the previous chapter, Devops are important to maintain code but guess what this is also a team effort, and on top of that it’s also a business critical priority, because with bad code comes bad things.

Coding “Free for all” meaning developers just develops how they feel like is far far away from how the code should be maintained in a great product code repository.

One of the overlooked “why’s” here is that the code is Intellectual Property (IP) owned by the company and has a monetary value if not in the accounting books then as a possible asset value if the company is sold. That alone makes it worth to keep the code maintained.

Further – why is it that the code should be readable and overview-able? The most important functions should be documented, at least high-level (it is extremely hard to keep documentation updated in a rapid development environment, and could slow down development a lot).

Having the code in a git repository ensures new versions can be added and you can always go back and track what was added by who, and if you used a task management system to manage your Backlog you can also track the ticket or task behind, making for a very good documentation of history.

This is useful to see why something was changed and what triggered it. By working in branches the developers have their own distributed copy of the code on their own computer and can collaborate easily by pulling an update of the code if another developer has been working on either the same branch or if new feature branches was added to the main branch during a production release.

Read more in "The CTO Playbook" available on Amazon/Kindle.