10. “A software system can best be designed if
the testing is interlaced with the designing
instead of being used after the design.”
11. “The good systems that are presently working
were written by small groups. More than
twenty programmers working on a project is
usually disastrous.”
12. "I bought my boss two
copies of The
Mythical Man Month
so that he could read
it twice as fast."
13. “The reason that small groups have succeeded (...) is
that there is a need for a certain structure of
communication, and a structure of decision making in
the development of software. This succeeds with small
groups, because it can all be done intuitively by one
person serving as most of the network. For large groups
to succeed, we (...) have to face organizational
structure for communications and decisions.”
16. 1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
17. 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.
18. 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.
20. “Design and implementation proceeded in a
number of stages. Each stage was typified by
a period of intellectual activity followed by a
period of program reconstruction”
21. “Each stage produced a usable product and
the period between the end of one stage and
the start of the next provided the operational
experience upon which the next design was
based.”
22. “In general the products of successive stages
approached the final design requirement;
each stage included more facilities than the
last.”
23.
24. “Selig’s picture requires a feedback loop, for
monitoring of the system. One must collect
data on system performance, for use in future
improvements.”
28. “I believe in this concept, but the implementation described above is
risky and invites failure. The testing phase which occurs at the end of
the development cycle is the first event for which timing, storage,
input/output transfers, etc., are experienced as distinguished from
analyzed. (...) then invariably a major redesign is required. A simple (...)
redo of some isolated code will not fix these kinds of difficulties. The
required design changes are likely to be so disruptive that the software
requirements upon which the design is based and which provides the
rationale for everything are violated. Either the requirements must be
modified, or a substantial change in the design is required. In effect the
development process has returned to the origin and one can expect up
to a lO0% overrun in schedule and/or costs.”
29. “Royce's 1970 paper is generally considered
to be the paper which defined the stagewise
"waterfall" model of the software process. But
it is surprising to see that (...) he already
incorporates prototyping as an essential step
compatible with the waterfall model.”
30. “The earlier Benington and Hosier papers had
good approximations to the waterfall model,
and that Royce's paper”
31. "Pitfalls and Safeguards in Real-Time Digital
Systems with Emphasis on Programming"
W.A. Hosier, 1961
34. “As soon as specifications a system program
are definitive, contractors should begin to
consider how they will verify the program's
meeting of the specifications.“
35. “"A requirements spec was generated. It has a
number of untestable requirements, with
phrases like 'appropriate response' all too
common. The design review took weeks, yet
still retained the untestable requirements."
45. “When we've talked about microservices a common
question is whether this is just Service Oriented
Architecture (SOA) that we saw a decade ago. (...) The
problem, however, is that SOA means too many different
things, (...) the fact that SOA means such different things
means it's valuable to have a term that more crisply defines
this architectural style.” -- Martin Fowler
46. “Alexander Pasik, a former analyst at Gartner, coined
the term SOA. (...) Pasik was driven to create term SOA
because “client/server” had lost its classical meaning.”
from “SOA in Practice: The Art of Distributed System Design” by Nicolai M. Josuttis
47.
48. “The common notion that Gartner Group
invented SOA is simply absurd. (...) the
underlying approach to distributed computing
was invented at least 15 years earlier.”
54. “The phrase ‘software engineering’ was
deliberately chosen as being provocative, in
implying the need for software manufacture
to be based on the types of theoretical
foundations and practical disciplines, that are
traditional in the established branches of
engineering.”
55. “The phrase ‘software engineering’ was
deliberately chosen as being provocative, in
implying the need for software manufacture
to be based on the types of theoretical
foundations and practical disciplines, that are
traditional in the established branches of
engineering.”
59. Towards engineering!
● Type System matters
● Functional Programming is our lord and saviour
○ statically typed
○ dependently typed
○ total
60. Towards engineering!
● Type System matters
● Functional Programming is our lord and saviour
○ statically typed
○ dependently typed
○ total
● Recognising Computer Science roots in math is essential to
write correct software
61.
62. if (a = 10) {
...
} else {
// will never be executed, variable a is changed!
}
The “beauty” of C++
Compiles!
And that’s a
bad thing
63. val a: Int = 10
if(a == “10”) “ten” else “sth else”
96. The Curry–Howard correspondence is the
observation that two families of seemingly
unrelated formalisms—namely, the proof
systems on one hand, and the models of
computation on the other—are in fact the
same kind of mathematical objects.
100. Constructive Logic (Intuitionistic Logic)
In mathematics, a constructive
proof is a method of proof that
demonstrates the existence of
a mathematical object by
creating or providing a method
for creating the object.
126. “We must know! We will know!”
While the roots of formalised logic go back to
Aristotle, the end of the 19th and early 20th
centuries saw the development of modern logic and
formalised mathematics.
127. “We must know! We will know!”
Question: could you derive all
mathematical truth using axioms and
inference rules of formal logic, in principle
opening up the process to automatisation?
128. “We must know! We will know!”
In 1929, Mojżesz Presburger showed that the theory
of natural numbers with addition is decidable and
gave an algorithm that could determine if a given
sentence in the language was true or false.
129. “We must know! We will know!”
“Bertrand Russell and Alfred Whitehead set out to
do something amazing.”
“Starting with just basic axioms of set theory, tried
to build complete edifice of mathematics as one
system, published as Principia Mathematica.”
130.
131.
132. Kurt Gödel
“On Formally Undecidable Propositions of
Principia Mathematica and Related
Systems” (1931)
Incompleteness theorem
133.
134. Kurt Gödel proved that for any system which
is at least as powerful to represent simple
arithmetic: either your system is incomplete
(i.e. cannot prove its own axioms) or it is
inconsistent (i.e. can derive a contradiction)
135. Kurt Gödel proved that for any system which
is at least as powerful to represent simple
arithmetic: either your system is incomplete
(i.e. cannot prove its own axioms) or it is
inconsistent (i.e. can derive a contradiction)
141. Kurt Gödel proved that for any system which
is at least as powerful to represent simple
arithmetic: either your system is incomplete
(i.e. cannot prove its own axioms) or it is
inconsistent (i.e. can derive a contradiction)
142. Kurt Gödel proved that for any system which
is at least as powerful to represent simple
arithmetic: either your system is incomplete
(i.e. cannot prove its own axioms) or it is
inconsistent (i.e. can derive a contradiction)
143. Automated Theorem Prover
It follows that an automated theorem prover will fail to
terminate while searching for a proof precisely when the
statement being investigated is undecidable in the theory being
used. Despite this theoretical limit, in practice, theorem provers
can solve many hard problems, even in models that are not fully
described by any first order theory.