
Pull Request Based Development Sucks - akkartik
http://lisperator.net/blog/pull-request-based-development-sucks
======
ehnto
The process you outline isn't really for the benefit of developers, at least
not entirely. It is for project managers and team leads. A PM isn't likely to
check the commit history and certainly won't be inspecting code comments to
find out why a ticket went over budget.

Similarly, the process enables many other things to occur such as the spec >
approve > develop > test > QA > stage > deploy workflow. That's a lot of
steps, where do you track who is responsible and when they worked on each step
if not in a ticket?

I am on your side however, when working on home projects or in small enough
teams, code flows much more quickly when you throw away those steps.

But if you don't see why the pull request based workflow makes sense then you
probably just don't need the features it adds to a project and that's fine.

A recurring issue in the tech industry seems to be small teams or sole
developers seeing tools and processes from enterprise level businesses and
thinking they need them.

Microservices solve a problem a small company likely doesn't have, for
example. Agile workflow for a sole developer can be streamlined significantly.
Vagrant or Docker and containers for someone who runs a single instance blog,
probably not worth the overhead.

Pick and choose what works for you and make sure you don't get yourself too
snowed in by process and tooling to get any work done.

