V05 Top Ten Software Engineering Concepts

Slide 1: Top Ten Soft ware Engineering Concepts Ed Yourdon & hordes of collaborators worldwide email: ed@yourdon.com Website: www.yourdon.com Blog: www.yourdonreport.com, Twitter: “yourdon” Version 05 Google Docs version Slideshare.net version green stuff = “internal” links to other pages in this document blue stuff = “external” links -- i.e., URLs to pages on the Internet Published under the GNU Free Documentation License (GFDL)

Slide 2: Publication Details, and General Disclaimer This “Web 2.0” GoogleDocs presentation is an open-content collaborative document. Anyone with an Internet connection and World Wide Web browser may view and/or alter its content -- for better or worse -- within the constraints of Google’s access mechanisms for such documents. Please be advised that nothing in this document has necessarily been reviewed by Ed Yourdon ("Ed"); the theories and business practices expressed by the “Web 2.0” document are not necessarily his. This isn't to say you won't find valuable and accurate information herein; however, Ed cannot summarily guarantee the validity of this “Web 2.0” document. The content of any given page may recently have been changed, dumbed-down, or other wise edited by someone whose opinion does not correspond to Ed’s original “Web 2.0” material (or any subsequent drafts). Neither Ed, nor any of the contributors, collaborators, nor anyone else connected with this “Web 2.0” document, can in any way whatsoever be held responsible for the appearance of any inaccurate information, or for your use of the information contained in or linked from this document. You are being granted a limited license to copy anything from this document; it does not create or imply any contractual or extra- contractual liability on the part of Ed, nor any of the contributors, collaborators, or viewers of this material. There is no agreement or understanding bet ween you and Ed regarding your use or modification of this information beyond the GNU Free Documentation License (GFDL); neither is Ed responsible should someone change, edit, modify, or remove any information that you may post on this “Web 2.0” document. Any of the trademarks, ser vice marks, collective marks, design rights, personality rights, or similar rights that are mentioned, used, or cited in this “Web 2.0” document are the property of their respective owners. Their use here does not imply that you may use them for any purpose other than for the same or similar informational use -- as recognized under the GFDL licensing scheme. Unless other wise stated, Ed and this “Web 2.0” document are neither endorsed by nor affiliated with any of the holders of any such rights; as such, Ed cannot grant any rights to use any other wise protected materials. Your use of any such or similar incorporated property is at your own risk. Published under the GNU Free Documentation License (GFDL) 2

Slide 3: 1.1.1 Global competition 1.1.2 Increased complexity 1.1 Why does it matter? 1.1.3 revenge of the user 1.2 Most ideas are not new But never got implemented 1.3 consistently 1 Introduction 1.4 Not rocket science 1.5 Common sense isn't common New generation must 1.6 rediscover basics Cultural/management issues more important than You can't 2.1 technical issues Technology is not the key 12.1 issue! control what 2.2 Core metrics : size, effort, defects, turnover 12.2 There are no silver bullet s you can't 2.3 Soft metrics - morale, user satisfaction Margaret Mead's 12 Conclusions 2 measure System dynamics - Brooks' 12.3 "prefigurative culture" Law 2.4 Don''t ignore new stuff: New twist: evidence -based 12.4 Chandler 2.5 scheduling 11.1 Bottom -up Best Practices Don't Reinvent 3.1 People are biggest productivity factor 11.2 Worst Practices (233 blogs!) 11 the Wheel 3 Peopleware Emulate Google's HR 3.2 strategy 11.3 SWBOK 3.3 Avoid teamicide Consistency 4.1 Prototypes are invaluable 10.1 Except in Silicon Valley (maybe) trumps Top Ten 4 Incrementalism 4.2 Daily build brilliance + Software Scope creep vs change 4.3 control 10.2 SEI -CMM I/ISO -9000 10 death -march Engineering Small mistakes early, rather Ideas 5.1 than big mistakes later Risk 5 Iteration 5.2 Doesn't have to be "all or nothing" Common issue in failed 9.1 projects Management 5.3 Refactoring 9.2 Shared risk management is crucial Provides Familiar techniques: RYG 9 Insights 6.1 Increases tenfold with each lifecycle phase "Top 10" list (example ) 9.3 Main issues are cultural , not Repair Costs 6.2 First observed in early 1980s 9.4 technical 6 Increase Agile crowd disagrees, 6.3 emphasizes refactoring Not just code! Design, But Boehm disagrees; may 8.1 specs, processes, plans, etc depend on project size 6.4 Web 2.0 version: API's to 8.2 support mashups Reuse Is 7.1 People -time tradeoff is 3rd order polynomial Technology less important 8.3 than business/cultural issues 8 Important Tradeoffs are Defects = k*FP**1.25 7.2 (Capers, p. 114) 8.4 Don't ignore cost of reuse 7 Non-Linear Hard to compute this in your 7.3 head! Need estimating tools for 7.4 rational negotiations! Published under the GNU Free Documentation License (GFDL) 3

Slide 4: Published under the GNU Free Documentation License (GFDL) 4

Slide 5: Top Ten Items Introduction 1. You can’t control what you can’t measure 2. Peopleware 3. Incrementalism 4. Iteration 5. Repair costs 6. Tradeoffs are non-linear 7. Reuse is important 8. Risk management provides insights 9. Consistency trumps brilliance + death-march 10.Don’t reinvent the wheel Conclusions Published under the GNU Free Documentation License (GFDL) 5

Slide 6: Introduction Why does this matter? • Global competition, pressure for faster/cheaper/better, etc • See “Shift Happens” and “Did You Know?” • Increasing complexity of systems, blah blah blah • New issue (Web 2.0): users can control their own technology; revenge of the user Most key soft ware engineering ideas are not new But they never got implemented consistently It’s not rocket science... ... but common sense isn’t common Each new generation doomed to rediscover basics Published under the GNU Free Documentation License (GFDL) 6

Slide 7: 1. You can’t control what you can’t measure Lots of good books, including Tom DeMarco’s 1982 classic, “Controlling Soft ware Projects,” and Paul Strassmann’s “The Squandered Computer” Cultural/management issues more important than technical issues (see 1987 classic by HP’s Robert Grady & Deborah Caswell, “Soft ware Metrics: Establishing a Company-Wide Program” Core metrics: size, effort, defects, turnover Soft metrics: morale, user satisfaction, etc. System dynamics -- e.g., Brooks’ Law (watch for forthcoming book, “Soft ware Process Dynamics,” by Ray Madachy) Published under the GNU Free Documentation License (GFDL) 7

Slide 8: 2. Peopleware People are (and always have been) the biggest productivity factor in projects Emulate Google’s HR strategy, and hire the best people you can Give them decent office space; and minimize interruptions in the work environment See “Meet the Life Hackers,” from Oct 16, 2005 New York Times. Based on 1,000 hrs of obser vations of t wo West Coast high-tech firms: “Each employee spent only 11 minutes on any given project before being interrupted and whisked off to do something else. What’s more, each 11-minute task was itself fragmented into even shorter three-minute tasks, like answering e-mail messages ... And each time a worker is distracted from a task, it takes 25 minutes, on average, to return to that task.” See report from ICSE 2007 panel session on “Celebrating Peopleware’s 20th Anniversary, in Sep 2007 IEEE Soft ware. Also available here (free!) on my blog. Avoid teamicide Published under the GNU Free Documentation License (GFDL) 8

Slide 9: 3. Incrementalism (vs. “big bang” development) Prototypes are invaluable Use the “daily build” approach Promote change management, beware scope creep and “scope churn” Published under the GNU Free Documentation License (GFDL) 9

Slide 10: 4. Iteration See classic 1970 paper by Win Royce, “Managing the Development of Large Soft ware Systems: Concepts and Techniques” Make small mistakes early, rather than big mistakes later Concept doesn’t have to be applied in an “ or all nothing” fashion More recent OO version: “refactoring” Published under the GNU Free Documentation License (GFDL) 10

Slide 11: 5. Repair costs increase if defects “leak” to later stages Increases tenfold with each lifecycle phase First documented by Barry Boehm in early 1980s Agile crowd disagrees, emphasizes continuous refactoring But Boehm disagrees; may depend on project size. See “Balancing Agility and Discipline: A Guide for the Perplexed” (2004) Published under the GNU Free Documentation License (GFDL) 11

Slide 12: 6. Tradeoffs are Non-Linear Tradeoff bet ween people and time is a 3rd order polynomial Capers Jones (p. 110 of “Estimating Soft ware Costs”) says: Defects = k*FP**1.25 Hard to compute this in your head! Need industrial-strength estimating tools for rational negotiation of non-trivial projects Published under the GNU Free Documentation License (GFDL) 12

Slide 13: 7 Reuse is important . Don’t just reuse code; also design, specs, processes, plans, budget templates, etc. Web 2.0 version: API’s to support mashups • Example: 6,000 apps developed with Facebook API in 5 months (from Mary Meeker, at 2007 Web 2.0 Summit conference, p. 37 of presentation) • Example: HousingMaps = Craig’s List + Google Maps • 275 Flickr Mashups • Funny example: Earth Sandwich • Funny example: George Bush + U2’s “Sunday, Bloody Sunday” • More amusement: Obama “1984” mashup Again: technology less important than business/ cultural issues Don’t ignore cost of reuse Published under the GNU Free Documentation License (GFDL) 13

Slide 14: 8. Risk Management provides insights Common issue in failed projects Shared risk management is crucial Familiar techniques: R-Y-G list of top 10 risks (example) Again: main issues are cultural, not technical Published under the GNU Free Documentation License (GFDL) 14

Slide 15: 9. Consistency trumps brilliance + death-march Except in Silicon Valley (maybe) Instead, focus on approaches like SEI- CMM, ISO-9000, six-Sigma, ITIL, etc, etc. Published under the GNU Free Documentation License (GFDL) 15

Slide 16: 10. Don’t Reinvent the Wheel Best Practices (bottom-up!) Worst Practices (233 blogs!) SWBOK Published under the GNU Free Documentation License (GFDL) 16

Slide 17: Conclusions Technology is not the key issue Fred Brooks: “there are no silver bullets” Margaret Mead’s “prefigurative culture” • See Michael Wesch’s commentary, “Vision of Students Today,” on how today’s Web 2.0 technology is affecting education for college students (also watch “the machine is (us)ing us”! • Note Oct 3, 2007 announcement: UC Berkeley announces it will publish its university lectures on YouTube Don’t ignore new stuff -- e.g., Chandler Published under the GNU Free Documentation License (GFDL) 17

Slide 18: 1.1.1 Global competition 1.1.2 Increased complexity 1.1 Why does it matter? 1.1.3 revenge of the user 1.2 Most ideas are not new But never got implemented 1.3 consistently 1 Introduction 1.4 Not rocket science 1.5 Common sense isn't common New generation must 1.6 rediscover basics Cultural/management issues more important than You can't 2.1 technical issues Technology is not the key 12.1 issue! control what 2.2 Core metrics : size, effort, defects, turnover 12.2 There are no silver bullet s you can't 2.3 Soft metrics - morale, user satisfaction Margaret Mead's 12 Conclusions 2 measure System dynamics - Brooks' 12.3 "prefigurative culture" Law 2.4 Don''t ignore new stuff: New twist: evidence -based 12.4 Chandler 2.5 scheduling 11.1 Bottom -up Best Practices Don't Reinvent 3.1 People are biggest productivity factor 11.2 Worst Practices (233 blogs!) 11 the Wheel 3 Peopleware Emulate Google's HR 3.2 strategy 11.3 SWBOK 3.3 Avoid teamicide Consistency 4.1 Prototypes are invaluable 10.1 Except in Silicon Valley (maybe) trumps Top Ten 4 Incrementalism 4.2 Daily build brilliance + Software Scope creep vs change 4.3 control 10.2 SEI -CMM I/ISO -9000 10 death -march Engineering Small mistakes early, rather Ideas 5.1 than big mistakes later Risk 5 Iteration 5.2 Doesn't have to be "all or nothing" Common issue in failed 9.1 projects Management 5.3 Refactoring 9.2 Shared risk management is crucial Provides Familiar techniques: RYG 9 Insights 6.1 Increases tenfold with each lifecycle phase "Top 10" list (example ) 9.3 Main issues are cultural , not Repair Costs 6.2 First observed in early 1980s 9.4 technical 6 Increase Agile crowd disagrees, 6.3 emphasizes refactoring Not just code! Design, But Boehm disagrees; may 8.1 specs, processes, plans, etc depend on project size 6.4 Web 2.0 version: API's to 8.2 support mashups Reuse Is 7.1 People -time tradeoff is 3rd order polynomial Technology less important 8.3 than business/cultural issues 8 Important Tradeoffs are Defects = k*FP**1.25 7.2 (Capers, p. 114) 8.4 Don't ignore cost of reuse 7 Non-Linear Hard to compute this in your 7.3 head! Need estimating tools for 7.4 rational negotiations! Published under the GNU Free Documentation License (GFDL) 18

Slide 19: Top Ten Soft ware Engineering Concepts Ed Yourdon and collaborators worldwide email: ed@yourdon.com Website: www.yourdon.com Blog: www.yourdonreport.com Version 05 Google Docs version Slideshare.net version green stuff = “internal” links to other pages in this document blue stuff = “external” links -- i.e., URLs to pages on the Internet Published under the GNU Free Documentation License (GFDL)