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.• 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.

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

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 – Prototypingthe ‘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 / pull-down

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.