3 ms·

Sure, but there are still workflows that are just plain bad[1], and articles like this one are an effective way of giving users better alternatives. [1] Last s

Sure, but there are still workflows that are just plain bad[1], and articles like this one are an effective way of giving users better alternatives. [1] Last summer I interned for a company that had recently switched to git. The workflow was: you are assigned a feature and begin developing it on the shared "development" branch. As you make commits you note the hashes on the company issue tracker. When the feature is finished and signed off, the DevOps people manually parse through all the comments on the issue, manually cherry-pick (!) every commit (that you remembered to write down) to the "production" branch, push, and hope they didn't miss any.

tmoertel 13y ago
The point I'm hoping to make is that there is no universal < operator on workflows that lets us rank them in a way that makes sense for most teams. Different teams necessarily have their own, widely varying < operators, and applying these operators to the set of plausible workflows causes wildly varying workflows to rise to the top. There are, however, workflows that are so bad that they rank poorly under your < operator, my < operator, and just about every other reasonable person's < operator. Your example makes this painfully clear. Still, someone at the company you interned at had an < operator that pushed that horrible workflow to the top of the list. You can argue that that person was crazy, and maybe you would be right, but maybe that person wasn't. Maybe that person's < operator accounted for things you couldn't see. Maybe the company needed the Git workflow to contort itself into integrating with legacy processes that would have been hugely expensive to change. Whatever the reason, that person's < operator is not one that you or I would want to have forced upon us. Why then should we assume our personal < operators good enough to force upon anybody else, let alone everybody else?

tmoertel 13y ago

The point I'm hoping to make is that there is no universal < operator on workflows that lets us rank them in a way that makes sense for most teams. Different teams necessarily have their own, widely varying < operators, and applying these operators to the set of plausible workflows causes wildly varying workflows to rise to the top. There are, however, workflows that are so bad that they rank poorly under your < operator, my < operator, and just about every other reasonable person's < operator. Your example makes this painfully clear. Still, someone at the company you interned at had an < operator that pushed that horrible workflow to the top of the list. You can argue that that person was crazy, and maybe you would be right, but maybe that person wasn't. Maybe that person's < operator accounted for things you couldn't see. Maybe the company needed the Git workflow to contort itself into integrating with legacy processes that would have been hugely expensive to change. Whatever the reason, that person's < operator is not one that you or I would want to have forced upon us. Why then should we assume our personal < operators good enough to force upon anybody else, let alone everybody else?