OpenShift is a private PaaS solution (Platform-as-a-Service) to build, deploy and run applications into containers. Open source, it is available under Apache 2.0 licence and released into 2 versions: Origin (community) and Enterprise.

Management 3.0 is definitely a trendy topic this year and the lucky participants of the USI 2015 event could directly hear about it by its author: Jurgen Appelo.

In addition to his talk at USI, Jurgen Appelo kindly accepted to answer our questions.

OCTO: What would you highlight as new / disruptive with Management 3.0?

Jurgen Appelo: What is new is to manage the system, not the people. For example for our merit money bonus system, I don’t decide who gets how much money, I don’t see that as my job. I think the crowd knows better who has what kind of performance, so I let them make the decision together. What I do is to make sure that this process works as well as possible. That is my responsibility, introducing such an idea. This is the same for many practices traditionally used by managers with higher positions than their employees.
I don’t see it as my responsibility to use a carrot and a stick in order to get someone to perform better. My job is to set up things in such a way that people love developing their own performance.Read more

In the previous article, we introduced a general overview of the code review practice as well as two specific formats we use in our projects.

Nevertheless, successfully introducing a new practice is not an easy task. It’s a bit like setting sail for the first time: once in the water, the first meters are always chaotic. There are lots of waves, we wonder whether it was really a great idea. Wouldn’t it be wiser to go back ashore? However, after a bit of dedication, we finally get to the quieter open sea: we just had to hold onto it.

During our code reviews, we came across several pitfalls that were detrimental and that could jeopardize code reviewing in the team.

Let’s explore, through real-life use cases*, why the first code reviews will certainly be difficult and what are the essential fundamentals to carry out successful code reviews.

Having written about monitoring flow and best practices for setting it up, let’s move onto a practical example. We’ll define a mini-information system combining services and messages, then we will show how to monitor it, including technical explanation and the full code.

We mainly use two code review formats in our projects: collective review which is rather formal and peer review, which is lighter. Both have advantages and drawbacks: Let’s look into these formats together and see how to implement them within a team.

But first things first: what is a code review and what benefits can we expect?

In most areas involving writing, we cannot imagine that what is written is issued without proofreading. An article will always be proofread before publication (e.g. the one you are currently reading), either to check the substance – is the subject of the article well treated? – or the form – spelling, grammar, structure and text readability. Similarly, the code review practice consists in having one’s code read again in order to track as many defects as possible, be it on the content – does this code work, and correctly implement the required feature? – or the style – clarity, readability, standards compliance, etc.

What about you: how many lines of code have you ever deployed in production without proofreading?