[acaloiar]

"If you ask any developer whether a slower development process is better, no one ever says yes. Nor do management or customers ever complain that your development cycle is too fast for them."

I've never known a developer not to speak up when the development cycle is too fast or a user who is not averse to the resultant buggy software.

[kitbrennan]

You're confusing 'development cycle' and 'pushing code'.

Pushing code too fast is clearly a problem that causes bugs, and neither developers or users are a fan of.

The 'development cycle' includes the total time to implement something, including time taken to fix resultant bugs.

Where you can speed up the development cycle without introducing more bugs (eg. by implementing comprehensive testing and QA practices), then no one is going to complain.

[acaloiar]

I think you draw an important distinction, but I don't believe that either of our comments are incorrect. I was explicitly referring to a development cycle that is too fast. After all, developers are humans and not machines. Perpetually fast development cycles lead to mental exhaustion, missed vacations--bugs. Unless, of course, you exist on a team that is staffed over-capacity such that the absence of any single developer has an immaterial effect on development cycles. I suspect that is not the case for most of us.

[Consultant32452]

I've had a customer complain that I was being too productive for their team of business/design folks to keep up. I literally got pulled aside and asked to slow down. I think it was making them look bad.

[wahnfrieden]

Faster dev cycles can be safe, even safer, as long as the changes are accordingly incremental. See the whole "continuous delivery" line of thought.