I’ve discussed with hundreds of developers about code reviews and how they implement this key process in their companies. Most of them mentioned, particularly in big companies, that they were asked to write huge documents defining the process, border cases, roles, potential exceptions, etc. It all sounded great, but there was something missing… none of those flows and roles defined were EVER implemented in their daily operation.

So here is where my questions arise, what’s wrong with code reviews? How does a company that doesn’t do code reviews starts to include them in its development process? How do companies make sure that defined policies (written in many documents, with many versions and approvals) actually happen and detect if the process is not working?

Meeting & more meeting is not the solution!

Some companies think that meetings are the solution for everything. I think completely the opposite, most of those meetings make things even worse. Creating more processes to manage the existing processes only generates more documents that no one ever follows (and a waste of time).

Meetings and more meetings

A Business Rules Engine: an automatic and simple way to reinforce your code review process

At Gitcolony, we love code reviews and we make sure they happen. We created a business rules engine that every company can fully customized to help you reinforce your code review policies and also informal practices.

Every time a rule is broken, an incident is created

You need to reinforce your processes but at the same time have alerts/notifications when something is not working as expected. Based on that, we created the concept of “Incidents” that would work like a server log, but for processes.

Based on Gitcolony’s business rules engine we detect potential issues so your team can tackle them before they actually happen.