Working Products

Working Products

Lecture 3CIS 6101 – Software Processes and

Metrics

Introduction• A working product at all times should be the ultimate goal for

every software team.• If far away, it’ll take time to get product back to a working state.

• Working Product does not mean product is feature-complete or that all features are done.

• Idea is to show product to customer (maybe for use) with the minimum possible number of unexplainable errors.

• Such working products are said to be ‘essentially shippable,’ because the product could be shipped after a short period of verification testing and stabilization.

• Team must keep product in a working state because a working product imparts greater flexibility and agility.

37 2

Working Product vs Working Software

• Working Product is meant to include not only the working software but also:– explicit deliverables such as documentation,

supporting infrastructure / web-site info and – implicit deliverables such as expectation that there has

been testing before the customer sees the product.

• Working Software is thus only a part of the working product.

37 3

Working Product Every Day (1/2)

• A working product is an underpinning of agile software development.

• Agile development demands ability to get continual customer feedback.– Only way is to keep customers interested and provide working software on a

regular basis.– Says to customers that ‘this’ is a product they can rely upon.

• Working product gives the team an incredible amount of flexibility – to change directions and ability – to take / ship current version of software w/critical features the market demands.

• Gives ‘power’ to development team from– Feeling in control, and using that control to respond to changing situations.

37 4

Working Product Every Day (2/2)

• By having a working product every day and fixing defects as you go :

– allows teams to focus on the customers,

– reduces the buildup of technical debt in the product, because chances are very high that problems are caught as soon as possible.

37 5

Working Products and Quality• To keep a product in a working state, teams need

to focus on the quality of everything they do!

• When product is in a non-working state and changes are being made to it, technical debt is accumulating – a debt to be repaid later..

• Cost of fixing errors increases with time • As well as increased probability multiple

problems will show up in the final product 37 6

Putting Things into Perspective

• To the team: What does it mean to ‘ship’ product every day to customers?

– Ship means provide daily updates or a complete new version of the software to install.

• Here are some issues: • And these are VERY REAL ISSUES if you desire to

‘ship’ proucts to customer every day…

37 7

Issues Shipping Every Day (1 of 4)

• Quality Assurance and Testing become critical– Ship every day?

• One person cannot do all testing automate as much testing as possible

• testing is threaded throughout development; integral to the process. Not an afterthought…

• Implies designing product and features for testability now as opposed to testing later. Need people available.

– Discuss: How do you design for testing???

37 8


• Is your documentation and web site going to be ready to reflect the new changes every day?

– Need to work out automated way of updating web site while ensuring documentation

• can be loaded off the Internet and not just the local hard drive (i.e., updated live)

37 9


• Must have your act together:

• What happens when customer finds problem?– How to report to you? – How to prioritize for urgent fixes?– How to minimize chances defect is fixed reliably w/o

breaking something else?

• When customer reports problem,– How to let customer know status of fix?– Let them know status of defect on line and when to

expect fixes?37 10


• How to develop features that take a long time?– Wrong answer: wait until feature is complete and integrate– Find way to integrate features in piecemeal while ensuring product

still works while telling users what to expect every day.• E.g. old A, C, D transactions. Let them try out the Add first….

– Get input from customers on the new features as they progress.

• What if critical feature breaks in a daily release?– Customers must be able to easily report problem to you and back

up to the previous day’s version while they wait for a fix.– Now you need to demonstrate responsiveness to your customers,

because this is costing them money and time.

37 11

Goal of Exercise – Ship Frequently• Ship product to customers as frequently as possible.

• Shipping encourages teams to minimize their overhead while maximizing productivity so they can ship frequently and implement the features the customers need.

• Shipping often is the ultimate goal.

• May be only possible to ship once a week or once a month• Avoid only being able to ship a couple of times a year.• Important to ship and get your software installed and used on

real problems as frequently as possible.37 12

Examples – Several Update Very Frequently

• Eclipse – a reliable update mechanism is built into the software so that updates can be made at any time.

• Renderware is a commercial game engine produced by Criterion that ships weekly

• Norton Anti-Virus is updated whenever a new virus has been detected on the Internet

• Microsoft regularly provides updates to Windows and Office tools. Its updates work.

37 13

Counter Examples: Mission-Critical Apps

• Not too practical for mission-critical systems where systems must be installed only after considerable caution.

• But most systems are NOT mission-critical.

37 14

Practices for Working Products

• 1. No Broken Windows (read on your own)• 2. Be uncompromising about Defects!• 3. Barely Sufficient Documentation

37 15

Practice 1 – No Broken Windows• Easy to make changes in a sloppy, haphazard way. • Once one sloppy change has been made, others will follow.

• Never start the decay. • Clean up bad code immediately.• Ugly workarounds cause problems and are a symptom that

the product is most likely not in a working state.

37 16

Practice 2 – Be Uncompromising about Defects

• Avoid a defect backlog! (List of Open Defects)

• Defect backlogs burden teams with repetitive searching, sorting, categorizing tasks– Huge maintenance / management tasks here too!– Takes away from productive work.

• A defect backlog makes it more difficult to find defects that MUST be fixed.

37 17

Practice 2 – Defect Backlog – continued (2 of 3)

• A defect backlog is a strong indicator – new features are being developed on top of defective

code.

• Longer the backlog:– greater probability backlog may never be eradicated.– greater probability defects shipped to customers.– greater time between defect introduced and fixed. the

greater the cost to fix it.

• Why do you think this is so?

37 18

Practice 2 – Defect Backlog – Continued (3 of 3)

• Be ruthless. – Decide to quickly fix it or mark that you won’t. – Once decided to fix, do so as quickly as possible.

• Fix regressions immediately! – Do before any other changes are made to product.

• Fix all known defects in a new feature before moving on to work on the next feature.

37 19

Practice 3: “Barely Sufficient” Documentation (1 of 3)

• So teams can concentrate on a working product, produce a minimal amount of time writing documents that are not part of the product, such as requirements and design documents.– Note: Talking about minimizing ‘internal documentation.’) – External documentation such as help and feature

documentation is required by customers and should be considered as features.

• Barely Sufficient Documentation is a feature of agile development.

37 20


• Sometimes documentation is required before a project can move on

• But this imposes a linearity in development which is unhealthy and unrealistic.

• Focus on what matters the most: working products.

• Customers often don’t really know what they want until they see it.

37 21


• Examples of Barely Sufficient documentation: – Use of index cards for feature description

• To describe essential facts• Gives something tangible for hands to discuss.

– Collection of feature cards• Should be adequate documentation of requirements.

– Design software collaboratively in front of a whiteboard. Great discussions!

– Alternatively, use a sketchbook.– Put design details like relationships and code rationale

w/source code (where it can easily be kept up to date) and extract them when using a tool such as JavaDoc.

37 22

Dangers of Excessive Documentation

• In a heavyweight development process, every feature had to be documented – every requirement, functional specifications, design documents, written test plans… bookshelves where kept.

• Review meetings held for each document.• Progress was very slow – revising, reviewing…

37 23


• 4. Continuous Integration• 5. Nightly Builds• 6. Prototypes

37 24

Practice 4: Continuous Integration

• Continuously integrate changes together.

• Frequent integration ensures modules fit, and product continues to work with the changes.

• Developers should integrate their work every day or many times a day.

• Naturally, your team needs automated testing to help catch integration problems.

37 25

Practice 5: Nightly Builds

• Completely build your software one or more times per day including as many automated tests as possible to catch integration problems early.

• Should be an installable product image always ready.• If build fails, fix first thing in morning!• No further integration until fix is done!!

• Builds should be fast; – if not, something is wrong with the structure of the product;

module dependencies, modules too large; worst of all, duplicated or unnecessary code

37 26

Practice 6 – Prototyping

• Prototype solutions to risky problems – helps increase chance of having a working product.

• Prototyping is an inexpensive way to try out new ideas so that successful implementation is more likely later.

37 27

Practice 6 – Prototyping the ‘True Prototype’

– The True Prototype– Here we test an implementation is used to understand a problem

before it is implemented for real.

– Prototype to get understanding of the risk • Perhaps prototype a solution to a problem to gain greater confidence you

understand the problem. • Great for trying out risky features!

– You also have an implementation to borrow from, even if it is only ideas, when implementing the complete solution.

– Doesn’t have to be software• Can be a paper prototype, white board, w sticky notes for buttons / pull-

down menus..37 28

Practice 6 – Prototyping the ‘True Prototype’• A prototype is a quick and dirty implementation that

explores key target areas of a problem. – Should not be production ready nor complete

implementation of desired solutions.– Use as a reference only when implementing the complete

solution to a problem.– Might even be implemented in a scripting language such

as Python or Ruby to save time.– But recognize that they are a point of reference only when

implementing the complete solution to a problem.• Downside – show to customers to demonstrate

progress; they feel product appears done – even though some of what they see may be hardcoded!37 29


• 7. Don’t neglect Performance• 8. Zero Tolerance for Memory and Resource

Leaks• 9. Coding Standards and Guidelines

37 30

Practice 7 – Don’t Neglect Performance• Passionate feelings:– Some: strive for code clarity more than

performance; then optimize the one to three percent of code that needs it.

– Others: code for performance first, because if you don’t, you code will always be slow.

– Code clarity should be first, but not at the expense of performance.

– You must be concerned with performance and with clarity, with a strong bias toward the latter.

37 31

Practice 8: Zero Tolerance for Memory and Resource Leaks

• If your environment (language, environment) does experience leaks, have zero tolerance!

• Resource leaks lead to unpredictable behavior such as program crashes, that can be exploited by hackers to compromise your customer’s computers.

• Unfortunately, some lower level APIs that your application may use may leak memory. What does it mean to ‘leak memory?’– You might free allocated resources if you can; sometimes you cannot.

• Sometimes in large applications when they stop it may take time for the OS to recover the available memory.

• Lots of issues here.• Try to avoid memory leaks as much as you can. • Some APIs hook up to your application to start and stop leak detection.

– Note: no memory leak is acceptable. Not true that only the big ones count. – A leak can put up a fence around the application’s primary memory such that the

system cannot reuse that memory. Not good.37 32

Practice 9 – Coding Standards and Guidelines

• What is good code and what coding practices team members like / dislike.

• Get team members to agree on practices / conventions; consistent coding conventions that make code easier to read / understand.

• Useful for others who join the team, as these will likely not be updated. – USAF: AFDSDC 300-8; The Software Development Process. – AFM 300-4, Data Elements and Codes.

37 33

Practice 10 – Adopt Standards• Don’t reinvent the wheel.• Reuse as much as possible via ‘value-added.’• One plum nowadays is Open Source. Lots of software available.• What Open Source is doing is significant.• Solutions can be offered.• Look at IBM: Eclipse IDE is open source project, but Ibm also

uses Eclipse as a foundation for its own commercial products and allows third parties to develop their own commercial products on top of Eclipse. Being a free IDE has created a large community of developers who are comfortable with Eclipse and are also potential buyers of IBM’s other tools.

37 34


• 11. Internationalize from the Start• 12. Isolate Platform Dependencies

37 35

Practice 11 – Internationalize from Day One.• Get into the habit of ensuring your products are

internationalized.• No extra overhead once you learn what is required.

• Most growth is expected outside of English-speaking nations.

• Implication is obvious. Think globally!

37 36

Practice 12 – Isolate Platform Dependencies

• If your code must support multiple platforms, a clean separation between – platform-specific code and – all the other code – is essential to have software that can be easily kept in a working state.

• Examples dependencies:– operating systems, graphic subsystems, runtime environments,

libraries, and user interface toolkits.

• Isolate platform dependencies via an abstract interface, such as a Façade design pattern) to that the majority of the software is isolated from the platform-dependent code.

37 37

Documents

Working Products