Joel,
I'm not sure that you could ever boil this issue enough to distil a single "right" answer. Think for a moment about methodologies...
In the classic, big-shop scenario, we see highly structured and formal project management methodologies (like Waterfall, perhaps) that pass the auditor's test for compliance to "best practice". In reality, almost nobody actually meet all of the documentation and process controls that these methodologies "require", in part because it is hard to conduct a formal, comprehensive design prior to entering development. Projects often get stuck in the design phase because the formality of the development methodology throws up roadblocks. In response, we've seen new methodologies that foster less up-front methodology. Most of these newer methodologies prove useful in the sense that design and documentation are a result of actual development activity, and the development team can quickly adapt to new or previously unconsidered requirements.
Ultimately, the "when" of deployment is a total non-issue. In all cases, there need to be checks and balances that must be cleared before a change to a production application takes place. If your shop has a policy for managing emergency fixes, then one only needs to initiate that policy to effect the needed change.
For normal development activities, the methodology will often drive the roll-out frequency. If your shop was using SCRUM, your "sprint" duration defines the schedule. Within the time that a sprint starts and stops, all development actions occur simultaneously within the scope of this sprint. A sprint includes many change requests, that are all to be delivered within the allotted timeframe. Any new requirements identified during this development effort may be rolled into the current sprint (if necessary), or added to the backlog of requests that will be serviced on an upcoming sprint. At the end of the sprint, the code rolls out of development (perhaps to QA) and ultimately into production.
Productivity of a particular methodology is often hard to measure. Let's define a request, and I'll try to explain how methodology impacts productivity...
Request1: User needs a new prompt screen on the Order Entry application.
Request2: Fix OE to not drop order lines if on-hand is 0.
Traditional methodology:
1) assign the request to programmer
2) programmer tries to check out Order Entry to acquire source code. If another developer is changing the Order Entry application, we must wait for them to complete the deployment cycle before we can start. This can often take days or even weeks for the change to pass all checkpoints (QA review, Change Approval Board approve the deployment, Operations group to distribute the change to production).
3) Write the code, test, promote, cab approval, etc...
4) Deploy individual change request...
Agile methodology:
1) assign the request to a sprint.
2) programmer takes the request, determines if source has been checked out yet... Check out OE if not already in sprint.
3) Write the code, test, then work on other requests assigned to the current sprint. Any other programmer with requests that apply to OE will add their changes to the source you already modified.
4) At end of sprint, all changes made during the sprint interval get deployed together.
-Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Thursday, April 26, 2012 10:36 AM
To: 'Midrange Systems Technical Discussion'
Subject: survey RESULTS: frequency of in-house coded software enhancement promotions to production
It appears that Iseries shops are split between anytime/daily (5 responses) and weekly (4 responses).
There was one shop (my shop) that has monthly promotions.
I was curious if this is common, and obviously it is WAY outside the norm.
Although 10 responses is a small sample, it is probably indicative of the norm to some extent.
Interesting asides:
* Two people expressed that they would like to see LESS frequent promotions (ie one was DAILY and would prefer WEEKLY, and one was WEEKLY and would prefer MONTHLY or even QUARTERLY).
(That seems opposite of what I would have expected)
* It would appear that SMALLER shops enjoy MORE frequent promotions, and LARGER shops have more constraints in place
* It probably depends on a person's perspective - for someone responsible for reducing risk; monthly or quarterly installs look best. For developers and users, daily promos may look most appealing.
It seems to me that once a shop gets past weekly promotions, the developer loses touch with what he did a month ago. When the promotion blows up, it is very difficult to get back into the frame of mind that he was working on 3 or 4 projects ago. That seems like REAL risk!
Thanks for your responses.
______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit
http://www.symanteccloud.com
______________________________________________________________________
midrange.com
