From: "Stone, Joel"
Please explain why you feel sorry for any environment with spaced-out
Just to be clear, we're talking about lengthening the time between moving new and changed software into production, right? Spacing out the time to weekly, monthly, quarterly, or perhaps even an unspecified interval? I assume that we're not talking about an arbitrary amount of time. That would be weird.
What are some of the downsides?
Users would be missing out of whatever good might be included in the additions and changes; unnecessarily, in many cases. That would be poor service from the IT group.
I would feel sorry in the same way that one would feel sorry for a person suffering from a disability or disease. Except in this case it would be an organization suffering from dis-function. It would be symptomatic of a larger problem; poor application architecture, inadequate automation of change management, poor quality systems, inadequate training or inexperienced personnel, lame testing procedures, poor application development languages, frameworks, and tools, lack of communication, disagreement, or perhaps an overly controlling boss.
I've worked in environments where major stakeholders could not agree on how to develop software, which languages and frameworks to use, which platforms to deploy on, what a UI should look and behave like. Major stakeholders thought they knew how to develop and deploy software, but they didn't. Not really. That's highly dis-functional. It's painful.
My goal would be to move new software into production as soon as it is ready. Where significantly scoped new and changed software could be moved into production daily.
I admit that there are cases where the impact of software changes could be so profound, the number of affected people so large, or the risk of disaster so great, that it may take significant time to promote changes into production.
On the other hand, the change might be a trivial inquiry or reporting application.