CSC 444 Software Engineering Software Releases CSC 444

CSC 444 Software Engineering Software Releases CSC 444 F'07 Lecture 3 1

Software Releases • The software vendor lives and dies the endless dance of the “release cycle” CSC 444 F'07 Lecture 3 2

A Release Lifecycle CSC 444 F'07 Lecture 3 3

A Simple Release Plan Dates: Coding phase: Jul. 1—Oct. 1 Beta availability: Nov. 1 General availability: Dec. 1 Capacity: CSC 444 F'07 Fred Lorna … Bill total days available 31 ecd 33 ecd … 21 ecd 317 ecd Requirement: AR report Dialog re-design … Thread support total days required 14 ecd 22 ecd … 87 ecd 317 ecd Status: 317 effective coder-days 0 effective coder days Capacity: Requirement: Delta: Lecture 3 4

Non-Coding Time and Resource • I explicitly plan coding only. – Other • types of resources: – Testers, documenters, managers • phases: – Specification, testing – these are sized relative to the coding phase and the coding resource • Why? – Debugged code is the ultimate target • Can’t be 90% done on that and still ship intended feature set – How much time to devote to documentation? – How much time to devote to testing? – When is enough, enough? • How? – – – Establish ratios Measure what works for ratios for a given product Adjust next time around Converges rapidly Initial guess is usually pretty good CSC 444 F'07 Lecture 3 5

Resource Ratios • Typical ratios I have used • Adjust to taste • Assumes availability throughout the (overlapping) release cycle. CSC 444 F'07 Lecture 3 6

Phase Length Ratios • • Typical ratios I have used Adjust to taste CSC 444 F'07 Lecture 3 7

Release Overlap • Overlapping release cycles smoothes resource utilization CSC 444 F'07 Lecture 3 8

Shipping The Release • • After dcut, proactive management is gone. Can only watch defect arrivals and hope for the best. – If your ratios are off: forgetaboutit, CSC 444 F'07 Lecture 3 9

Release Concepts & Terminology CSC 444 F'07 Lecture 3 10

Cost of Feature Releases • Considerable overhead associated with a feature release: – – – – • System testing Marketing collateral Launch events Customer/partner briefings New training courses and materials New training internally New CD’s to burn. . . Largest cost of them all – Increased maintenance burden from supporting an extra release in the field • • • Reproduce bug in each codeline Decide what/when to fix Re-test Re-release Maintenance releases are much less costly – Regression tests will do it CSC 444 F'07 Lecture 3 11

Supporting Simultaneous Releases • Generally must support at least 2 feature release maintenance streams. • Usually must support 3. • MUST try to hold the line at 3. • Else all the maintenance will erode the company’s ability to respond in a timely fashion to changing market conditions. • Opportunity cost of developers – A trained developer is scarce resource – New features or maintenance – Opportunity cost of maintenance is the revenue the feature they might have coded could have brought in. CSC 444 F'07 Lecture 3 12

maintenance R 1 shipping R 1. 0 private big new feature X retired shipping R 1. 1 maintenance R 2 shipping R 2. 0 shipping R 2. 1 maintenance R 3 shipping R 3. 0 shipping R 2. 2 shipping R 1. 1 R 2. 2. a ongoing CSC 444 F'07 active Lecture 3 13

Time Between Releases • Feature releases are costly: – Therefore increase the time between feature releases. • But, customers want more features – Therefore decrease the time between feature releases • But, they also want stability in their own IT environment – Therefore increase the time between feature releases. – Sometimes customers get very sticky on old releases – Need to make the new release compelling to end-users • What if one customer or prospect wants a new feature? – New feature release? – Probably not • What if the market condition changes rapidly? – Cut short current release to rush it out? – Go back to last release, extend it, and put that out? – Costly: because of short release cycle will need to support >3 releases in the field. CSC 444 F'07 Lecture 3 14

Pushing Back • A successful development manager will need to distinguish between people asking for things that can be pushed off, and truly urgent things. – Everything is presented as the latter • Track the request back to its source personally. – Will learn the true nature of thee request. – Can deal with 80% of “urgent” requests in this manner CSC 444 F'07 Lecture 3 15

Features in Maintenance Releases • Tried pushing back • Cannot justify a new feature release • Customer/prospect still wants/needs features earlier than the next scheduled feature release • What now? • Slip new features into a maintenance release. • In theory, maintenance releases should change no externally visible program behavior (other than to correct it if faulty). • What the heck, do it anyways. • Does not have the cost of a new feature release. • Why not? CSC 444 F'07 Lecture 3 16

Costs of Features in Maintenance Releases • BASIC RULE: – Cannot introduce new code without introducing new defects • Two reasons for introducing new code: – Fix a defect – Code a feature • If only doing defect corrections: – Fix 2 add 1: the trend is good: -1 – Will eventually get them all (asymptotically) – Converging quality • If also doing new features: – Fix 2 add 1, add a new feature, add 4: the trend is poor: +3 – Diverging quality CSC 444 F'07 Lecture 3 17

Negative Leveraging • The new feature is only useful to one customer. • The defects introduced as a result can negatively impact every customer. • Because touching code risks breaking ANYTHING, ANYWHERE • Customers get irate if a “maintenance release” breaks previously working functionality – Danger even when just fixing defects – Gets much worse if adding features CSC 444 F'07 Lecture 3 18

Release Proliferation • If software quality is poor in general, customers will be slow to upgrade to a release they consider will be more buggy. – Can lead to supporting many releases in the field. • EVEN WORSE: If customers come to fear maintenance releases, they may be reluctant to leave a maintenance release. – They may insist that you fix any issues as patches to their maintenance release – This is catastrophic release proliferation, whereby every point releases turns into a maintenance stream of its own. . . CSC 444 F'07 Lecture 3 19

Does this apply to Web App dev? • • • Absolutely, yes. Seems to be easier to deploy web apps than installed apps. Largely illusory – Installed apps can have “update from web” feature, so is just as convenient – With web app you own all the data, so have to take extra time to not only write the software to migrate the data, but also test the deployment. • Must still test the whole app, which is the largest part of the overhead of a release. • All the other considerations also apply. • Management asks me regularly “is this something that we can do between releases? ” – My answer is almost always “no” – Of course you can technically, but my answer comes from a deeper understanding of the issue where the correct answer for a software professional is “no” because of the loss of productivity and danger of defects escaping into the field. CSC 444 F'07 Lecture 3 20

Mitigating the Consequences • If absolutely forced to, then: • Have a very good regression testing environment • Segregate functionality using run-time configuration switches – Code review to ensure when off, no new code touches the system CSC 444 F'07 Lecture 3 21

Versions • As distinguished from “releases”. • Different variants of the same software – Differ in small ways Must Support: • stream of maintenance releases for each version • each feature release will continue to ship that version • ideally at the same time Version reasons: Hard to Undo the decision to support a new version: • some customer now relies on it CSC 444 F'07 Lecture 3 • multiple hardware platforms • multiple os’s • multiple databases • multiple app frameworks • multiple partner software • security • functional tiers • demoware • translations 22

Cost of Versions • Surprisingly costly to support many versions – Not the development cost: relatively cheap – just another feature – Ongoing maintenance costs • Technical means: – different code (linked differently or #ifdef’d) – run-time switches (e. g. , dynamically detect version of Windows and change API calls appropriately). – different dev platform and tools – binary-compatible: different test environments • In any case: – testers must test all supported versions – coders must bear in mind they are supporting multiple versions – must track down bugs in each version and fix CSC 444 F'07 Lecture 3 23

Version Proliferation • Software company will support many versions in hopes sales will increase – each version opens up a new market segment • Danger: too hastily commit to supporting too many versions • Be aware of costs and push-back • If in the business of supporting many versions: – architect the software well to support it – construct a superb multi-platform automated build/test environment CSC 444 F'07 Lecture 3 24

Customized Software • A different variant of the software for important customers – Static methods: require a distinct executable – Dynamic methods: same executable • run-time switches • alternate dll’s • If customization required on feature release boundary – evaluate if feature’s dev opportunity costs are worth the revenue • If customization required sooner – either: • carefully insert changes into the point release stream • #ifdef all code and build a unique executable for the customer – Can we merge the changes into the next feature release? – Nothing very palatable here • Better to build in enough configurability that customers do not require customizations – gui-based configuration – scripting-based configuration CSC 444 F'07 Lecture 3 25

User Extension API • Allows customers to implement their own features into the software • Danger: – must support the API forever more – even if one already exists internally: • • • clean it up identify public versus private APIs document it train customers on it hire programmers to provide help desk support on it – support becomes “debug the customer’s code” • maintain it unchanged – do not inadvertently change behavior • market it and sell it • consult on it – write it once – support it forever? » paid/unpaid? CSC 444 F'07 Lecture 3 26