The document discusses software engineering theory and practice. It covers topics such as understanding requirements before writing code, the costs of bugs introduced at different stages of development, and common fallacies around software development. It also discusses writing code to facilitate understanding, creating beautiful code, and predicting future trends such as the growth of data and new forms of accessible information.

1. Software Engineering:
Theory and Practice
David Hyland-Wood
david@zepheira.com, dhylandw@umw.edu
1

2. Agenda
Theory
Practice
Understanding before doing
Beautiful code
Guessing the future
2

3. Theory
3

4. Lost in Terminology
Software metric primitives are non-
isomorphic:
“defect”
“resource”
“programmer”
“time”
4

5. Lost in Terminology
Entailment?
I need help
*FINDING*
my tail!
http://www.flickr.com/photos/efleming/237379205/
5

6. 60/60 Rule
Cost of software
over entire lifecycle
6

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. Three Fallacies
The Fallacy of Perfect Knowledge:
It is possible to capture complete, non-conflicting
requirements with sufficient attention to detail.
8

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. Three Fallacies
The Fallacy of the Big Round Ball:
Requirements don’t change appreciably after
delivery or can be controlled.
10

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. Three Fallacies
The Fallacy of Perfect Execution:
It is possible to create flawless code with
sufficient attention to detail.
12

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

15. The Real World is
Soft and Mushy
(With apologies to S. Gross)
15

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

19. New Applications
19

20. And More....
20

21. Understanding Before Doing
Some material adapted from Kurt Akeley,
General Manager, Microsoft Research Asia, 21 July 2006
21

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. 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. “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. “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. Write First
No
Research & Write Up Yes
Done? Stop
Develop Results
?
26

27. Beautiful Code
27

28. What Does Your Code
Look Like?
28

29. A Hardware Analogy
29

30. Another Hardware Analogy
30

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. 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. Guessing the Future
33

34. Writing Business
Applications
Data
formatted
Code written
1970s 1980s 1990s 2000s
34

35. Same Data, Different Forms
Human
Readable
Machine
Readable
35

36. Getting to the Web 2.0+
Enterprise
Thanks to CBS Paramount Television. TM & Copyright © 2007 CBS Studios Inc.
36

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. Don’t Focus on Code
Solve problems instead
Start thinking about information spaces
Navigating
Creating
Extracting From
Extending
Abstraction, abstraction, abstraction
38