A few weeks ago a colleage mentioned in an argument that in contrast to open source communities, where mutual distrust between many personally unknown contributors is prevalent, in a corporate environment due to the contracts of all developers trust can be assumed. Therefore, some specific – but out-of-scope of this article – practices cannot be taken over to corporate environments. It made me think.
I concluded today that there has to be a differentiation. One has to distinct between trust in people and trust in code/results.
It may be true or not true, that in corporate environments there is more trust, because many contributors know each other personally from regular meetings, sitting next to each other in an office and, maybe most influencial, by the nature of their contracts. Of course we all are also aware of the sources of corporate distrust, mainly politics and personal agendas. One could also argue that in Open Source projects there is more trust among contributors because of the mutual mindset, nice conferences and legends of old mailing list battles against each other or united against some guys from the other paradigm (indentation anyone?). I would say its in every organization’s highest interest, to nurture and foster trust among the developers, most importantly trust in the fact that all are doing the best they can with best intentions. An organization in which people think others are intentionally blocking or even destroying their progress is toxic and will lead to significant problems sooner or later (or needs to be covered with effort, money, time, …).
My point is that trust in code is never good. Its a bold statement, but look at your own environment. Are you 100% trusting the code you work with? I would not. Do you trust the Pull Request from someone without looking at it? I would not. Do you trust your own code you have produced today? Yeah maybe, but when you look at it in one year you should have at least a critical perspective. Some genius developers think their code is always perfect (and it may very often be). I dont think it is. There is also strong evidence that thinking your code is perfect doesnt make you a good developer. A good developer knows about the dangers coming with every written line of code. Almost every code can be source for trouble. It can contain bugs, it may call other code which is buggy. Even if its absolutely bug-free today, tomorrow a compiler issue, weird build pipeline or hardware glitches may break it (and rather than solving the root cause you may be forced to update your code with a nasty workaround). Some may say that viewpoint is depressing, and it is a bit. But neglecting the facts is not sustainable. It is the daily struggle of our industry.
Coming back to my colleague’s argument I would say: In our corporate project we have about the same amount of trust among team members like in an open source community of comparible size and we work hard every day to improve the basis for trustful collaboration. But we should also be always distrustful with the code we produce ourselves and the code we get from external parties.
And there is and should be no difference between open source projects and corporate environments regarding trust in people and distrust in code.
Looking forward to get your comments on this.
(I posted this article also on LinkedIn)