DEV Community

Cover image for Pull or not to pull
Elmar Dott
Elmar Dott

Posted on

Pull or not to pull

Pull requests like they are known from GitHub gets more and more popular in enterprise software development. This workflow also known as dictatorship or with his adaption to dictator-lieutenant, is a well proven process for open source projects. But in my perception - I always ask my self: We do really want this in commercial projects? I don’t think so. Because we already had in the past a tool called IBM Synergy with an equal approach. It was very heavy weighted and companies who used Synergy was looking quite fast to replace the software for better solutions.

Well, pull request now integrated into close to every DevOps tool, for Example Microsoft Azure and so on. Of course they absolutely more light weighted than the IMB Synergy workflow. But there is a big misunderstanding in commercial projects. Tools like Git, Subversion or Bazaar are just a storage for developer collaboration. Not a quality gate. The reason is quit easy explained.

A build manager is usually not be able to decide if a implementation fits well to the architecture. This are tasks for an Architect. In my humble opinion, I think a better and less time consuming strategy in enterprise projects, are code reviews shortly before a sprint is closed or directly after the sprint. Then, all the code is integrated and the metric tools deliver better results on test coverage, code smells and code duplication. Pull requests stresses developers more than they increase their implementation skills.

Before you start a lot of activities in the hope as overall result you project reach a better quality, you should wait and think twice. Don't run - take a breath and think about what you really wish to make better in your project. There many aspects about quality. B. W. Boehm published in 1975 a research paper how to define quality and how it can measured. May you want to have a look on my DZone article about software quality.

If you have the idea to use pull request to secure the quality for your off shore vendor team, you might be wrong. You should select well educated developers for a higher price, which delivers better code because of their experience. There is a great book about how to work together with off shore development teams, written from Nick Krym “Outsource It!”. [2012, The Pragmatic Programmers, ISBN-13: 978-1-93778-505-5]

Top comments (0)