Working Products

1. Working Products Lecture 3 CIS 6101 – Software Processes and Metrics

2. Introduction • A workingproductat 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 (if appropriate) show to customer (maybe for use) with the minimum possible number of unexplainable errors. • Such working products are said to be ‘essentiallyshippable,’ 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.

3. Working Product vs Working Software • Working Product is meant to include not only the working software (commonly-used term) but also other • explicitdeliverables such as documentation, supporting infrastructure / web-site info and • implicitdeliverables 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.

4. Working Product Every Day • 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 workingsoftware 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.

5. Working Product Every Day • By having a working product everyday and fixingdefectsasyougo : • 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.

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

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

8. 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 • Implies designing product and features for testability now as opposed to testing later. Need people available.

9. 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 updated web site while ensuring documentation • can be loadedoff the Internet and not just the local hard drive (i.e., updated live)

10. 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, • How to let customer know status of fix? • Let them know status of defect on line and when to expect fixes?

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

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

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

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

15. Practices for Working Products • 1. No Broken Windows (read on your own) •  2. Be uncompromising about Defects! •  3. Barely Sufficient Documentation

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

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

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

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

20. 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.’) • Externaldocumentation 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.

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

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

23. 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…

24. Practices for Working Products •  4. Continuous Integration •  5. Nightly Builds •  6. Prototypes

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

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

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

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

29. 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!

30. Practices for Working Products • 7. Don’t neglect Performance • 8. Zero Tolerance for Memory and Resource Leaks •  9. Coding Standards and Guidelines

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

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

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

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

35. Practices for Working Products •  11. Internationalize from the Start •  12. Isolate Platform Dependencies

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