|
> So that brings me back to where I came in: do you experience any concrete, measurable benefits from the "excellent development velocity" you mentioned, or is it simply your team's preferred development style? Yes, see the following: > The customers love it, and we enjoy excellent stability and development velocity. These are the reasons we deploy many times a day. There's no reason for us not to deploy things once they are tested and ready. We're not just deploying bug fixes quickly (which you seem to be fixating on a bit), we are constantly making small iterations. If we're handling support and see something that could be improved, we improve it and roll it out quickly. If we have a moderate sized feature branch, it is merged, tested, and rolled out immediately as soon as it passes QA. No need to set a rigid "We only deploy on Wednesdays" schedule. Pass QA, deploy immediately. > Not if it's for a bug fix or security patch, but presumably most of your development work is adding new features? In that case, isn't the whole point that it's something the user will notice? No, a huge chunk of dev time is spent iterating on and improving existing features. There gets to be a point in a product's life cycle where you are more or less feature complete, where the emphasis shifts to refining and improving what you already have. Sure, there are new features, but if you never iterate, you've got older stuff accumulating dust and ageing badly. |