SLIDE 1
“A software system can best be designed if the testing is interlaced with the design, instead of being used after the design”
- Who and When???
Engineering You Lynn Langit - @lynnlangit Martin Thompson - - - PowerPoint PPT Presentation
Engineering You Lynn Langit - @lynnlangit Martin Thompson - - - PowerPoint PPT Presentation
Engineering You Lynn Langit - @lynnlangit Martin Thompson - @mjpt777 A software system can best be designed if the testing is interlaced with the design, instead of being used after the design - Who and When??? A software system can
SLIDE 2
SLIDE 3
“A software system can best be designed if the testing is interlaced with the design, instead of being used after the design”
- A. J. Perlis (1968)
SLIDE 4
SLIDE 5
SLIDE 6
SLIDE 7
How many generations of programmers have we?
SLIDE 8
ISO 9001/27001 CMM
SLIDE 9
Engineering
SLIDE 10
The term Engineering is derived from the Latin ingenium, meaning "cleverness" and ingeniare, meaning "to contrive, devise".
Source: Wikipedia
SLIDE 11
Circa 1300 “One who operates an engine”, where engine is a military machine such as a catapult.
Source: Wikipedia
SLIDE 12
Later the term “Civil Engineering” was introduced to cover those specialising in non-military projects
Source: Wikipedia
SLIDE 13
Engineers must work within constraints. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productivity, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable
- bject or system may be produced and operated.
Source: Wikipedia
SLIDE 14
Engineers must work within constraints. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productivity, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable
- bject or system may be produced and operated.
Source: Wikipedia
SLIDE 15
Engineers must work within constraints. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productivity, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable
- bject or system may be produced and operated.
Source: Wikipedia
SLIDE 16
Engineers must work within constraints. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productivity, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable
- bject or system may be produced and operated.
Source: Wikipedia
SLIDE 17
Engineers must work within constraints. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productivity, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable
- bject or system may be produced and operated.
Source: Wikipedia
SLIDE 18
“Software Engineering”?
SLIDE 19
http://dl.acm.org/citation.cfm?doid=363717.363722
SLIDE 20
SLIDE 21
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
SLIDE 22
The design process is an iterative one:
- 1. Flowchart until you think you understand
the problem.
- 2. Write code until you realize that you don’t.
- 3. Go back and re-do the flowchart.
- 4. Write some more code and iterate to
what you feel is the correct solution.
SLIDE 23
I just want to make the point that reliability really is a design issue, in the sense that unless you are conscious of the need for reliability throughout the design, you might as well give up.
SLIDE 24
The good systems that are presently working were written by small groups. More than twenty programmers working
- n a project is usually disastrous.
SLIDE 25
Another interesting concept we might apply is that used in the Air Force, to fly a number of hours each month, in order to retain one’s ‘wings’.[…] In a situation where code actually has to be produced, nobody should be allowed in the system who doesn’t write some given number of lines of code per month.
SLIDE 26
SLIDE 27
http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
On the cruelty of really teaching computing science
- Edsger W. Dijkstra
SLIDE 28
Radical Novelty
SLIDE 29
One has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate.
SLIDE 30
Earlier scientific examples are the theory
- f relativity and quantum mechanics;
later technological examples are the atom bomb and the contraceptive pill.
SLIDE 31
Divide and Rule Decomposition on an unprecedented scale
SLIDE 32
Amplification of Changes Changing a single bit can have the most drastic consequences
SLIDE 33
We are all a product of our
- wn experiences
SLIDE 34
Uncomfortable Truth
SLIDE 35
SLIDE 36
SLIDE 37
SLIDE 38
What? Where? How?
Learning
SLIDE 39
What should you learn?
Algorithms & Data Structures
SLIDE 40
What should you learn?
Algorithms & Data Structures Design Fundamentals
SLIDE 41
What should you learn?
Algorithms & Data Structures Design Fundamentals Programming Paradigms
SLIDE 42
What should you learn?
Algorithms & Data Structures Design Fundamentals Programming Paradigms Decomposition & Abstraction
SLIDE 43
What should you learn?
Algorithms & Data Structures Design Fundamentals Programming Paradigms Decomposition & Abstraction Mathematics
SLIDE 44
What should you learn?
Algorithms & Data Structures Design Fundamentals Programming Paradigms Decomposition & Abstraction Mathematics Communications*
SLIDE 45
Monolith
SLIDE 46
From where can we learn?
Personal Practice
SLIDE 47
From where can we learn?
Personal Practice People & Teams
SLIDE 48
From where can we learn?
Personal Practice People & Teams Research Papers
SLIDE 49
From where can we learn?
Personal Practice People & Teams Research Papers Reading Code
SLIDE 50
From where can we learn?
Personal Practice People & Teams Research Papers Reading Code Projects – Tackle Unknowns First
SLIDE 51
From where can we learn?
Personal Practice People & Teams Research Papers Reading Code Projects – Tackle Unknowns First Online Resources
SLIDE 52
SLIDE 53
How can we learn?
Automate Repetitive Tasks
SLIDE 54
How can we learn?
Automate Repetitive Tasks Focus on Feedback Cycles
SLIDE 55
How can we learn?
Automate Repetitive Tasks Focus on Feedback Cycles Experimentation
SLIDE 56
How can we learn?
Automate Repetitive Tasks Focus on Feedback Cycles Experimentation Measure
SLIDE 57
How can we learn?
Automate Repetitive Tasks Focus on Feedback Cycles Experimentation Measure Apply Scientific Honesty
SLIDE 58
How can we learn?
Automate Repetitive Tasks Focus on Feedback Cycles Experimentation Measure Apply Scientific Honesty Revisit & Refine
SLIDE 59
SLIDE 60
“What can go wrong?”
SLIDE 61
SLIDE 62
25% Ignored Errors
SLIDE 63
In Closing…
SLIDE 64
SLIDE 65