[StavrosK]

Deploying frequently when you're 1-2 developers is much easier, usually. A very important predictor of code quality that I've found is gut feeling, and, when I feel pretty confident about a piece of code, it usually turns out fine. There have been times when I said "hmm, this 3-line change doesn't feel right" and it turned out to have a bug in it, so I rely on intuition a lot (tests can't catch everything).

When you've only got a few, experienced developers, it's much easier to ask "hey, how do you guys feel about the changes?" and push if everyone's fine. With larger teams or less experienced people, you need to go through more testing, which slows things down.

[buro9]

Oh, the government issue was that they would outsource management of the data centers and server management. The incentives in these outsourced contracts rewarded uptime and little else, and the best way to ensure that was to penalise anything that threatened it... such as a new release.

The end result, is that to have a patch deployed you'd have to get the patch, the whole codebase, and everything replicated and proven elsewhere (with realistica data and use cases), and a third party was contracted to do this.

It became insanely expensive to do even the smallest thing to make users or project sponsors happy... we couldn't give them code in any timely way, so everything became workarounds.

And you'd always find some project that would fight with this so much that they'd start writing in back doors. Auto-generating a WSDL on one occasion revealed a method for running arbitrary SQL. I guess some dev got sick of waiting 6 months for the next answer they needed.

[StavrosK]

I'll file this under "corporate horror stories" :)

I was more referring to how easy it is to push frequently to production when you have a small team of good developers, though. As the team gets larger, the ease of pushing to production drops (leading to your example above, in the long run and with crappy dev culture, I guess).