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.
• The further the product is away from being in a working state
and the longer it is in that state, the greater the time required
to get the product back to a working state.
• Working Product does not mean product is feature complete
or that all features are done. Rather, that it can be shown to or
given to a customer 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.
Working Product vs Working Software
• Working Product is meant to include not only the
working software (commonly-used term) but also
other
– 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.
Working Product Every Day
• A working product is an underpinning of agile software development.
• Agile development demands ability to get continual customer feedback.
– Only wayis 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.
Working Product Every Day
• The Working Product principle is in deliberate contrast to
traditional code-then-fix method (the most common) of
software development.
• By having a working product every day and fixing defects
as you go
– minimizes wasted effort,
– 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.
• All attempts must be made to prevent defects from
reaching people whether they are testers or customers.
Working Products and Quality
• To keep a product in a working state, teams need to focus on the
quality of everything they do!
• Focus on the quality of the product and the discipline to ensure
every software modification passes an extensive suite of automated
tests or it is removed from the product until it does pass the tests.
• When product is in a non-working state and changes are being
made to it, development team is literally flying blind and technical
debt is accumulating – a debt that will have to be repaid later..
• Cost of fixing errors increases with time as does the probability that
multiple problems will show up in the final product or be found at
customer sites.
Putting Things into Perspective
• To the team: What would it take for us to ship
our product every day to customers?
– Ship means provide daily updates or a complete
new version of the software to install.
– Causes team to think about minimizing overhead
activities that occur when software is declared
complete
• Here are a few topics:
Issues Shipping Every Day
• Quality Assurance and Testing become critical
– Ship every day?
• One person cannot do all testing  automate as much testing
as possible
• Implies designing product and features for testability now as
opposed to testing later. Need people available.
• Is your documentation and web site going to be
ready to reflect the new changes every day?
– Need to work out automated way of updated web site
while ensuring product documentation can be loaded
off the Internet and not just the local hard drive (i.e.,
updated live)
Issues Shipping Every Day
• 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?
• How to develop features that take a long time?
– Wrong answer: wait until feature is complete and integrate
– Must find a way to integrate features in piecemeal while ensuring product still
works and while telling users what to expect every day.
– Need to 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
prevoius 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.
Goal of Exercise – Ship Frequently
• Ship product to customers as frequently as possible.
• Shipping frequently encourages teams to minimize their
overhead while maximizing their 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.
Examples
• Several open source projects and some
commercial products can ship every day or at
least very frequently.
– Eclipse – a reliable update mechanism is built into the
software so that updates can be made at any time.
– Qt – a commercial GUI cross-platform toolkit
– 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.
• Not too practical for mission-critical systems
where systems must be installed only after
considerable caution.
• But most systems are NOT mission-critical.
• Users tend to expect poor quality and to not be
able to continue to do their jobs when they
perform a simple software upgrade.
• We should focus on working products and this
should be the rallying cry for development teams.
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.
Practice 2 – Be Uncompromising about Defects
• Avoid a defect backlog! Where the list of open defects is
too large for the team to deal with immediately.
• Defect backlogs burden teams with repetitive searching,
sorting, categorizing tasks….takes away from productive
work.
• A defect backlog makes it more difficult to find defects that
MUST be fixed.
• A defect backlog is a strong indicator that new features are
being developed on top of defective code.
• Longer the backlog, greater probability backlog may never
be eradicated.
• Longer the backlog, greater probability defects will be
shipped to customers.
• Greater the time between when a defect is introduced and
when fixed, the greater the cost of fixing it!\
Practice 2 – Be Uncompromising about Defects
• Be ruthless. Decide as quickly as possible to fix it
or get rid of it (mark that it won’t be fixed and
why…)
• Fix regressions immediately! Do before any other
changes are made to product.
• Once decided to fix, do so as quickly as possible.
• Fix all known defects in a new feature before
moving on to work on the next feature.
• Put more effort into preventing them than fixing.
• Defect detection is vital; defect prevention is
more vital. (put in safeguards: QA departments)
Practice 3: “Barely Sufficient” Documentation
• 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.
• (We are 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.
• Sometimes documentation is required before a project can move on –
imposes a linearity in development which is unhealthy and unrealistic.
Remember what matters is the process – the conversations / decisions
required to produce a useful product.
• Focus on what matters the most: working products.
• Many projects work for years understanding requirements and writing
documents before any product or code. Customers don’t really know
what they want until they see it.
• Documents don’t help customers at all.
Practice 3: “Barely Sufficient” Documentation
• Examples of Barely Sufficient documention:
– 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
with the source code (where it can easily be kept up
to date) and extract them when using a tool such as
JavaDoc or doxygen.
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…
Practice 4: Continuous Integration
• Continuously integrate changes togethe.
• Frequent integration ensures modules fit
together, and product continues to work with
all 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.
Practice 5: Nightly Builds
• Completely build your softwre one or more times per
day including as many automated tests as possible to
catch integration problems early.
• Should be an installable product image.
• 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; too many dependencies
between modules, not enough modules, or worst of
all, duplicated or unnecessary code
• Entire team owns the Product Build.
Practice 6 – Prototyping
• Making a conscious effort to prototype
solutions to risky problems helps to increase
the chance of having a working product.
• Prototyping is an inexpensive way to try out
new ideas so that as many issues as possible
are understood before the real
implementation is made.
Practice 6 – Prototyping
the ‘True Prototype’
• Two types of prototyping
– The true prototype, where a test implementation is used to
–
–
–
–
understand a problem before it is implemented for real.
All projects have risk and risk must be constantly assessed.
When identified, one must do something to ensure risk is well
understood
Prototype to get understanding of the risk – perhaps prototyping a
solution to a problem to gain greater confidence that you understand
the length of time required to understand the problem. You also
have an implementation you can 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 / pulldown menus..
• Throwaway prototypes
– An excellent tool to evaluate risky features and develop better time
estimates for feature development.
– Ensures that the basic product is still likely in a working state.
– 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 and they feel
that the product appears done – even though some of what they see
may be hardcoded!
Practice 6: Prototyping – Tracer Bullets
• Tracer Bullets:
– Here, from the outset the prototype will evolve into a final
solution.
– Start by building a viable prototype and keep addint to it
until customer says, ‘That’s it!’
– In a way, this is a microcosm of agile development where
multiple short iterations are used to continually add to a
prototype.
– But the difference is that agile development is applied to a
collection of features (a whole product) and tracer bullets
can be used on one feature or one area of risk…
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.
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.
– Can only report to vendor
– 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.
• We have today APIs that can 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.
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. Need to be quickly
understood; standards.
• USAF: AFDSDC 300-8; The Software
Development Process.
• AFM 300-4, Data Elements and Codes.
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.
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!
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.
• Some examples of platform are 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.