3 ms·
Really it’s the cynical engineers, me included, being skeptical about an unholy alliance of two tools known for their occasional slinging of hand grenades into
by setquk 8y ago
Really it’s the cynical engineers, me included, being skeptical about an unholy alliance of two tools known for their occasional slinging of hand grenades into the workflow.
In fact both tools effectively compromise the underlying concepts they encapsulate.
GitHub for example ties you to a very centralised model. The moment there’s a github problem, the whole “post push” workflow falls to its knees. Forget CI, PRs, everything. It’s down or working incorrectly or inconsistently until github find the poo and shovel it. When your old self served SVN server had downtime measured in seconds in a year and your build infrastructure was several orders of magnitude more reliable. Genuinely, it’s worse and needs more humans to keep it ticking on medium sized teams. That’s less humans on adding business value.
JIRA itself is an interesting tool. The tool itself has its own problems (abysmal performance mainly) but the main problem is that it has a propensity to be configured by people who don’t know or understand it. That results in many staff effectively running around in a hamster wheel every time they have to do something trivial.
These two together multiply and you end up with thousands of hours of developer time thrown out of the window. This is seen as the status quo of development but it doesn’t need to be.
We need better more reliable tools, not better integrations between pits of despair. Also we need a firm stick to beat the workflows into shape.