Michael Grünewald recently posted this comment:

A very important method you do not mention is the “four-eyes principle” which is used in the finance – either as a regulatory obligation or as a safe-guard. In the software industry it is implemented in various ways, as e.g. code reviews but also can be used to validate commands affecting live systems.

Correct me if I'm wrong, but I was taught that the "four-eyes principle" is about something that is "approved to happen", after at least 2 human beings (and/or automated processes) gave their prior blessing. Or to use the (slightly corrected) wording about the "two-(wo)man rule" from Wikipedia:

The two-man rule is a control mechanism designed to achieve a high level of security for especially critical material or operations. Under this rule all access and actions requires the presence of two authorized people at all times.

Regulatory obligations are, pretty sure, off topic here, but in the context of "safe-guard", what are the possible conceptual implementations of this four-eyes principle, which probably could apply to any platform / OS / hardware being used?

3 Answers 3


One of the implementation on code is the Pull Request model (PR) popularized by GitHub.

The main reasoning behind is that only a small set of maintainers of the product will be allowed to merge code into the release branch. Every new feature/bugfix will happen on a new branch and once done will be defined as a pull request.

This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way (Travis being the most popular for public project actually) and give a first feed back on the code quality. Travis CI (for example) can run on the result of actual master with the code from the pull request merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code

Once the automatic tests have passed, for the 4 eyes principle, it still requires a configurable number of persons to review and approve the change before it gets merged obviously at least 1 person (who is not the PR author) to enforce 4 eyes reviewing the changes.

There's a wide range of options to merge automatically once the quorum of reviewers is met or to still need a manual merge by a maintainer.

The permissions to review and merge can be separated which helps giving more people the right to "vote" on the merge status while keeping the possibility to restrict who can actually do the merge.

  • Please check the minor edit of your answer (typos stuff). If you don't like them, just rollback or re-edit, ok? Also, I hadn't thought about these PRs, so for sure very applicable I think. I'm going to mark this answer as accepted (I "learned" something from it,the things in my own answer I knew of course myself). Though I don't guarantee in the future I might change my mind (unaccept) should an even better answer get posted. About: "This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way", I don't get that, should I post a new question?
    – Pierre.Vriens
    Commented Mar 13, 2017 at 18:03
  • @pierre you're free to change your mind as often as you wish :) For the testing of proposed code, Travis CI (for exemple) can run on the result of actual master with the pull request code merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code. FWIW, googling sound the best approach IMHO, the subject is large
    – Tensibai
    Commented Mar 13, 2017 at 20:18
  • @pierre and for the edit, just one point , 4 eyes principle is to have 1 more person to review, that means 2 persons did view the change (the author didn't review it), hence the singular on variable number of person (as it could be only one, and in French maybe only one is singular :p) . I'm not as fluent in English as I'd wish to be, but I think the first point is valid (2 readers, 2 did view it making it a single review), for the second I may be biased :)
    – Tensibai
    Commented Mar 13, 2017 at 20:25
  • aha, that's what you mean, now I get it (and took the liberty to copy/paste the extra clarification into your answer). BTW: example (in EN), not exemple (as in FR) ...
    – Pierre.Vriens
    Commented Mar 13, 2017 at 20:41
  • @Pierre.Vriens blame the auto correct with dual language :)
    – Tensibai
    Commented Mar 13, 2017 at 20:42

Code Reviews

This is about having at least 1 other person look at the code written by somebody, eg to evaluate if it meets some predefined criteria like:

  • Coding standards (indentations, etc).
  • Inline documentation.
  • Maintainability of the code.
  • Error handling.
  • Completeness (eg if/then/else or case/when constructs cover all possible cases).

Approvals to update some target environments

This is about having at least 2 confirmations from some person and/or automated system before it is allowed to update some target environment (which may be live, or may be something like some master file / baseline library). Some examples are:

  • Only a limited set of warnings are allowed when transforming (building) source components in executable components.
  • Some set of automated tests must have completed without any probems.
  • Some human beings must have indicated their prior approval (and without that, any attempts to update the target environments will automatically fail).

These are strategies/patterns I can think of:

Separation of Duty

DevOps, to my view at least, does not means embodying of both dev and ops in a single person. So it is still possible to separate the duty such that the one writing the code (dev) is not the one executing it (ops).

For example, if an SQL statement is to be executed on the live environment, one writes the SQL and another executes it. What this presupposed is the the one executing need to also have an understanding of the SQL and not just execute.

Deploy trigger

While there are merit to continuously deploy. Team in a more regulated industry can appoint another (separate) party to trigger the deploy instead of deploying automatically. Checklist, automated tests, checksums are possible checks before triggering deploy.

Once triggered, the automation can go ahead to execute the deployment.

Pair Programming

Personally I have not cited this technique as a method to auditor to satisfy the check and balance principle. But potentially I think it can be a strategy.


I might be stretching a little with this one, but it is possible that for some reason that you don't want unilateral entry into a system, someone can hold the password and another person hold the token or device for one time code. So that, 2 person must be present to assess the system.

  • Merci for these interesting variations! Never heard of that "Pair programming" before, that really seems like a variation of playing a piano with "4 hands"!
    – Pierre.Vriens
    Commented Mar 23, 2017 at 18:47
  • 1
    I recently interviewed with a company that does the most intensive form of pair programming I've ever seen. They had "pod" setups with two machines, each with one dedicated monitor and one shared monitor. ALL development was done in pairs. It's not for everyone, but by all reports it works well for them. Commented Mar 23, 2017 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.