E N D
1. Quality Douglas Crockford
Yahoo!
http://www.crockford.com/codecamp/quality.ppt
3. The Software Crisis Over budget
Over time
Unreliable
Requirements not fully met
Unmaintainable
Failure
Insecure (New!)
4. Software Crisis Year 48
It is old news, so no one talks about it
In other news, the Sun will exhaust its supply of Hydrogen
5. Craft v Engineering
6. Computer Science has not taught us how to manage software projects
7. Software Construction In some ways like any other sort of construction.
In some ways radically different.
8. The Nature of Software Software is powerful and malleable
That is its blessing
That is its curse
9. Programming is Difficult Software is the most complicated stuff that humans make
10. Lack of metrics Measure of quality or completeness
11. Lines of Code Not an indicator of quality
Not an effective measure of completeness
Estimation is difficult
12. Programmers are optimists They wouldn't be able to do this work if they were not
13. Programmers do not understand how they spend their time
They think they mostly are typing programs
Mostly they are in meetings or technical conversations
Or staring at the screen saying "My God. What have I done?"
14. Programmers do not understand how they spend their time
Programmers tend to be skeptical of process improvements that might require more keystrokes.
First Rule of Optimization: Optimize the process that is taking the most time.
15. Programming is a social activity Solo projects are the exception
16. Cost of Innovation Doing what has been done before
v
Doing what has not been done before
17. Legacy In other industries, the wealth of practice and tradition
In software, past accomplishments are considered a liability
The age at which programs become legacy is getting younger and younger
Some programs become legacy before they are finished
18. Leaps Software is not governed by Moore's Law
Software is governed by Murphy's Law
Software leaps tend to come at 20 year intervals, not 2 year intervals
Cycle of software generation closely related to cycle of human generation.
19. Leaps Leaps make it possible to implement projects of greater complexity.
Adoption of leaping software technologies tends to be very slow.
Controversy.
Reluctance.
20. Leaps Plugboards
21. Leaps
22. Leaps Plugboards
Machine Code
23. Leaps Plugboards
Machine Code
High Level Languages
24. Leaps Plugboards
Machine Code
High Level Languages
Structured Programming
25. Leaps Plugboards
Machine Code
High Level Languages
Structured Programming
Object Oriented Programming
26. Object Oriented Programming 1967 Simula
1972 Kay begins Smalltalk
1980 Smalltalk released
1985 C++ Programming Language
1995 The Java Programming Language
2004 PHP 5
27. Leaps Plugboards
Machine Code
High Level Languages
Structured Programming
Object Oriented Programming
Distributed Programming
28. Failed Leaps Artificial Intelligence
Fifth Generation Languages
Computer Aided Software Engineering
Subjective-oriented, etc.
29. Software does not have enough self awareness to be afraid of bugs. That's why it works as well as it does.
30. Bugs Mr Edison, I was informed, had been up the two previous nights discovering a bug in his phonograph.
Pall Mall Gazette, 1889-03-11
31. Grace Hopper's Bug
32. Snake Oil Silver Bullets
33. Mythical Man Month (1975) Fredrick Brooks
"Adding manpower to a late software project makes it later."
Second System Effect
Prototyping (software is like waffles)
"A project becomes a year late one day at a time."
34. Literate Programming Donald Knuth
Programs are designed to be read.
The program is the specification and documentation.
35. Incrementalism
36. Beta Perpetually unfinished
37. Winchester House
38. Winchester House
39. Winchester House
40. Application Triad Skill
Training and experience
Technology
Work with technology providers and standards bodies
Requirements
Better understanding of the impact of requirements determination and crisis
42. Mr Blandings Builds His Dream House (1948) Best movie ever about project management
Blandings's problems:
Lack of knowledge of technology
Poor control over requirements
43. Feature Cost Development Time
Deployment Cost
Maintenance Cost (bloat, cruft)
Download Time
User Confusion/Training
Bug Delivery
44. Code Value A significant fraction of our valuation is the state of our codebase.
A low quality codebase is a liability.
45. Code Quality Microview: Coding Conventions
Macroview: Program Architecture
46. The simplest thing we can do to enhance the value of our codebase is to make our programs readable.
47. Distinguish Invocations return(value);
if(blah)
foo (wah)
function(){} return value;
if (blah)
foo(wah)
function () {}
48. Programs are a medium of intentional communication
Communicating detailed instructions with the machine
Communicating with your development community
Communicating with yourself
49. Good architecture is necessary to give programs enough structure to be able to grow large without collapsing into a puddle of confusion
50. Changing a correct program into another correct program.
51. Cruft Software Scar Tissue
52. Causes of Cruft Premature optimization
Inexperience
Misread source
Feature enhancement
Death March
53. Bloat Software Obesity
54. Insecurity Marginal security
55. Good secure programming is good programming.
56. It is not unusual for the purpose or use or scope of software to change over its life.
57. As cruft accumulates, complexity grows, progess slows. Eventually, the codebase itself becomes a huge source of friction
58. Refactoring The process of code refinement.
Correction of formatting.
Insertion of documentation.
Removal of cruft and bloat.
Restructuring.
59. Plant and harvest your crops for six years,but let the land rest and lie fallow during the seventh year
Exodus 23:10-11
60. Sometimes the best course is to start over
61. The Pain of the Crash Loss of a week's work, a day's work, an hour's work, is unbearable.
62. The illusion of completion "It's in the can."
63. An experienced team can cross that ground again very quickly. Focus must be on simplicity to avoid the second system effect.
64. Have regular code readings. Don’t wait until release to do code reviews.
Do team code reading regularly during development.
Problems can be discovered early.
Good techniques can be shared early.
Experienced developers can lead by example.
Novice developers learn from the group.
65. Have regular code readings. Frequent.
Helpful.
Respectful.
66. Conclusion Quality First. Quality Last.
Readable Code. Code Reading.
Invest in the quality of your code base.
Invest in your programmers and managers.
Quality is the most important feature.