What they don’t tell you: Software Engineering lessons

1. What they don’t tell you:Software Engineering lessons Sriram Srinivasan (“Ram”) sriram@malhar.net

2. Good design comes from Experience Experience comes from making bad mistakes Sriram Srinivasan

3. Today, you’ll learn .. • To look at methodologies with a critical eye • What worked for me, and what didn’t • QA practices adopted for a successful commercial product • WebLogic Application Server (www.bea.com) Sriram Srinivasan

4. OO is wonderful • Application == system of interacting objects • Guides thinking, partitioning the problem • RUP provides different views • Structural view of data, processes • Class diagrams • Dynamic view • Use cases • Sequence diagrams, State charts • Focus on data and data flow Sriram Srinivasan

5. Case Study #1: OO thinking • One of the world’s largest courier companies • Project: To come up with a company-wide business object model • Re-engineer all systems with this model • Promote reusability across the enterprise Sriram Srinivasan

6. Case Study #1 : Lessons learnt • “Business objects”: nebulous concept • Reusability – dubious goal • Clear problem statement • “Replace a legacy system” is not a goal. • Don’t think “object”, “web”, “computer” UML when learning a domain • Systemic thinking – includes manual processes Sriram Srinivasan

7. Case Study #2: Components • Objects vs components • Remote objects, Remote components • CORBA, DCOM, Java RMI • Enterprise JavaBeans, DCOM+MTS, .NET • My experience, from both sides: • Used remote components for a large aircraft scheduling application, network management systems • Wrote a CORBA server • Wrote the world’s first EJB framework Sriram Srinivasan

8. Case study #2: Lessons • Business Object Models do not translate well to code • Mismatch between RDBMS and objects • Network not transparent • Duplication between object framework and RDBMS: concurrency, transactions, security • Using objects to generate UI: bad idea • All designers must be active programmers Sriram Srinivasan

9. Other delivery issues • Customers want cheap, fast, good • Constant change • Requirements, technologies, business practices, programmers • Documents and Code mismatched soon • Proposed solution: eXtreme Programming (XP) Sriram Srinivasan

10. Extreme Programming • Kent Beck, Ward Cunningham • Stresses customer satisfaction • Focus on attitude • simplicity (in documentation, in coding) • communication • feedback • courage: embracing change • RUP and XP coexist happily Sriram Srinivasan

11. XP Practices • Planning • Writing User Stories (use cases) • Each story implementable in ~ 3 weeks • Release and Iteration planning • Sort stories by desirability • Designing • Simple: Only accommodate what's needed now, not for the future • Design evolves as project evolves • Customer available throughout the project Sriram Srinivasan

12. XP Practices (contd) • Coding • Implement and deliver a story at a time • Write unit tests first • Don’t write more code before exisiting tests succeed • Pair Programming • Continuous Refactoring, Integration • Collective ownership • Testing • All code must pass unit tests • All bug fixes accompanied by more tests Sriram Srinivasan

13. XP pitfalls • Types of software projects • Shrinkwrap, embedded, games, throwaway, internal IT projects • Most methodologies apply to internal IT projects • Customer is not always available • Not much chance of repeated versions in embedded software and games Sriram Srinivasan

14. XP pitfalls • Pair programming doesn’t work well • Ego clashes, mismatched experience levels, need for unstructured think time • Pair desigining, debugging works well for me • Erring on the side of too less documentation, less design • Problem with inexperienced XP’ers. • Larger projects require more structure • Refactoring costs time Sriram Srinivasan

15. What works for me • General • Meeting notes, emails, random ideas, prototypes archived and indexed • Every team project has a web-site • PowerPoint instead of verbose documents • Daily short meeting • Requirements phase • Problem statement (not list of features) • Design • User Interaction first: objects later Sriram Srinivasan

16. What works for me (contd) • Programming • Write unit tests first • Source code control, frequent integrations. • Assertion checks throughout • Peer code reviews • Tools: Profiler, Coverage & Thread analyzer • Design docs updated as design changes • Test for performance • System Test • Web test tools • Post-mortem Sriram Srinivasan

17. QA @ BEA • www.bea.com • Weblogic Server • Market leading Java application server for the last seven years • Testers and programmers in same room • Several tiers of testing Sriram Srinivasan

18. Tier 1: Build and Test “Monkey” • Fast, basic sanity check of recent checkins • Build and test in clean-room environment • Rule by shame • Monkey spams engineering for build or test breakage listing suspects • Performs broad-spectrum functional test • (3000+ test cases) that should always pass • Status viewable through intranet • Tools: Inhouse testing framework, WebLogic itself used as intranet webserver Sriram Srinivasan

19. Tier 2: Nightly • Nightly functional testing (same tools as earlier) • Quarter-million test cases in 12 hours across 5+ codeline branches • Partial JDK, OS, RDBMS platform matrix coverage • Daily report to all WLS engineering via web page • QA folks analyze and summarize report each AM • Longevity testing • Web based test tools Sriram Srinivasan

20. Tier 3: Weekly • Full functional testing • Full JDK and platform and protocol coverage • Full database coverage • Full 3rd party integration coverage • Performance testing • Loadrunner, mercury interactive, grinder • 30,000 client loadrunner configuration on ES4500, E10000 • Stress tests, applications like ecPerf, ePizza, PetStore • Sun J2EE CTS Sriram Srinivasan

21. Tier 4: Monthly • Manual GUI testing • Packaging/download testing • Installation verification • Examples testing • Complexity/coverage analysis • McCabe software metrics • Usability testing • Each bug tracked independently. Bug fix requires test case name • Regression tests Sriram Srinivasan

22. References • General • The Mythical Man Month,Fred Brooks • About-Face: Principles of User Interface design, Alan Cooper • The Inmates Are Running The Asylum, Alan Cooper • Bringing Design to Software, Terry Winograd • The Design of Everyday Things, Donald Norman • Software Engineering • www.joelonsoftware.com, Joel Spolsky • www.holub.com, Alan Holub • www.ObjectMentor.com, Robert Martin • www.nakedobjects.org Sriram Srinivasan

23. References • Extreme Programming • eXtreme Programming Explained, Kent Beck • www.extremeprogramming.org • xprogramming.com • Extreme Programming Installed • Ronald Jeffries, Ann Henderson, Chet Hendrickson • Extreme programming considered harmful • www.avoca-vsm.com/downloads/downloads.html • UI • www.useit.com, Jacob Nielsen • www.uidesign.net • www.cooper.com Alan Cooper Sriram Srinivasan

24. References • Distributed computing • A Note on Distributed Computing, Jim Waldo et al • www.sunlabs.com/techrep/1994/abstract-29.html • WebLogic Application Server • www.bea.com Sriram Srinivasan