Working Products
Lecture 3
CIS 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.
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
Issues Shipping Every Day (2 of 4)
• 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
Issues Shipping Every Day (3 of 4)
• 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,
37
– How to let customer know status of fix?
– Let them know status of defect on line and when to
expect fixes?
10
Issues Shipping Every Day (4 of 4)
• 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
Practice 3: “Barely Sufficient” Documentation (2 of 3)
• 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
Practice 3: “Barely Sufficient” Documentation (3 of 3)
• 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
Practices for Working Products
•  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
Practices for Working Products
• 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
Practices for Working Products
•  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