Umw Software Engineering Guest Lecture 05 Sep2007

1,448 views

Published on

Published in: Technology, Spiritual
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,448
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Umw Software Engineering Guest Lecture 05 Sep2007

  1. 1. Software Engineering: Theory and Practice David Hyland-Wood david@zepheira.com, dhylandw@umw.edu 1
  2. 2. Agenda Theory Practice Understanding before doing Beautiful code Guessing the future 2
  3. 3. Theory 3
  4. 4. Lost in Terminology Software metric primitives are non- isomorphic: “defect” “resource” “programmer” “time” 4
  5. 5. Lost in Terminology Entailment? I need help *FINDING* my tail! http://www.flickr.com/photos/efleming/237379205/ 5
  6. 6. 60/60 Rule Cost of software over entire lifecycle 6
  7. 7. Understanding and Bugs Causes of bugs: Cost of repair: The greatest number of bugs The greatest cost is incurred in occur in requirements correcting requirements bugs specification and design 7
  8. 8. Three Fallacies The Fallacy of Perfect Knowledge: It is possible to capture complete, non-conflicting requirements with sufficient attention to detail. 8
  9. 9. Three Fallacies The Fallacy of Perfect Knowledge: It is possible to capture complete, non-conflicting requirements with sufficient attention to detail. Users generally do not know what is possible, do not agree among themselves and may not understand all aspects of their system. 9
  10. 10. Three Fallacies The Fallacy of the Big Round Ball: Requirements don’t change appreciably after delivery or can be controlled. 10
  11. 11. Three Fallacies The Fallacy of the Big Round Ball: Requirements don’t change appreciably after delivery or can be controlled. Requirements change continuously as software ages. This should be seen as a benefit. 11
  12. 12. Three Fallacies The Fallacy of Perfect Execution: It is possible to create flawless code with sufficient attention to detail. 12
  13. 13. Three Fallacies The Fallacy of Perfect Execution: It is possible to create flawless code with sufficient attention to detail. We need to admit that arbitrary logic is hard to verify in the general case, hard or impossible to fully test and, combined with inconsistent or changing requirements, hard to trace programmer intent. 13
  14. 14. Practice 14
  15. 15. The Real World is Soft and Mushy (With apologies to S. Gross) 15
  16. 16. A History of Silos $ cat foo.txt | grep blah | sort 1970s 1980s 1990s A neat little package Client-Server The Early Web 16
  17. 17. The Next Great Leap Extending the Ubiquitous, Universal Client reusable applications Expanding the Explaining the Logic Universal Connection Web of Data Providing the Universal Database 17
  18. 18. Examples 18
  19. 19. New Applications 19
  20. 20. And More.... 20
  21. 21. Understanding Before Doing Some material adapted from Kurt Akeley, General Manager, Microsoft Research Asia, 21 July 2006 21
  22. 22. The Cost of Failure “If you can’t code something, it is because you don’t understand it” -- Jon Butler Sadly, the reverse is not true. 22
  23. 23. Writing Facilitates Understanding The process of writing is the process of refining one’s thoughts. Refinement of thought applies to writing both words and code. 23
  24. 24. “This, surely, is the secret of Lincoln’s eloquence. He not only read aloud, to think his way into sounds, but wrote as a way of ordering his thought.” — Garry Wells In Lincoln at Gettysburg Simon & Shuster, 1992 24
  25. 25. “Don’t worry if you don’t understand this book completely on the first reading. We didn’t understand it all on the first writing!” — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (aka The Gang of Four) In Design Patterns, Addison Wesley, 1995 25
  26. 26. Write First No Research & Write Up Yes Done? Stop Develop Results ? 26
  27. 27. Beautiful Code 27
  28. 28. What Does Your Code Look Like? 28
  29. 29. A Hardware Analogy 29
  30. 30. Another Hardware Analogy 30
  31. 31. “Higher-level programming ... allows good programmers to write more beautiful code, and bad programmers to write stuff that's even uglier than it used to be.” — Andy Oram & Greg Wilson (eds.) Beautiful Code, O’Reilly, 2007 31
  32. 32. Creating Beautiful Code Beauty counts “Omit needless words!” -- Strunk and White Develop a habit of refactoring for both design and maintenance The art changes; keep up 32
  33. 33. Guessing the Future 33
  34. 34. Writing Business Applications Data formatted Code written 1970s 1980s 1990s 2000s 34
  35. 35. Same Data, Different Forms Human Readable Machine Readable 35
  36. 36. Getting to the Web 2.0+ Enterprise Thanks to CBS Paramount Television. TM & Copyright © 2007 CBS Studios Inc. 36
  37. 37. The Information Economy 2003 24B 40,000 BCE 2002 12B cave paintings bone tools GIGABYTES writing paper 2001 6B printing 2000 3B electricity, telephone transistor computing Internet (DARPA) The web Source: UC Berkeley School of Information Management and Systems, Robert Steele, CEO OSS, Inc. 2000 rich content 37
  38. 38. Don’t Focus on Code Solve problems instead Start thinking about information spaces Navigating Creating Extracting From Extending Abstraction, abstraction, abstraction 38

×