thoughts on the software process - mit opencourseware · › developers rely on platform that turns...
TRANSCRIPT
![Page 1: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/1.jpg)
softwarestudio thoughts on software process
Daniel Jackson 1
process orderings
2
local vs global process
global ordering of phases local ordering of phases 3
risks
4
risk-driven development
Risk = Prob(failure) x Cost(failure)
a strategy rsaquo list failures amp determine their risks rsaquo devise a strategy to reduce highest risks
sample failures how would you mitigate rsaquo performance is unacceptable rsaquo product is unusable because its too complex rsaquo customer changes mind about what product does rsaquo developer solves the wrong problem rsaquo product fails in catastrophic way rsaquo competitor beats you into marketplace rsaquo product has reputation for bugs rsaquo development runs out of time and money rsaquo developers rely on platform that turns out bad
5
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 2: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/2.jpg)
process orderings
2
local vs global process
global ordering of phases local ordering of phases 3
risks
4
risk-driven development
Risk = Prob(failure) x Cost(failure)
a strategy rsaquo list failures amp determine their risks rsaquo devise a strategy to reduce highest risks
sample failures how would you mitigate rsaquo performance is unacceptable rsaquo product is unusable because its too complex rsaquo customer changes mind about what product does rsaquo developer solves the wrong problem rsaquo product fails in catastrophic way rsaquo competitor beats you into marketplace rsaquo product has reputation for bugs rsaquo development runs out of time and money rsaquo developers rely on platform that turns out bad
5
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 3: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/3.jpg)
local vs global process
global ordering of phases local ordering of phases 3
risks
4
risk-driven development
Risk = Prob(failure) x Cost(failure)
a strategy rsaquo list failures amp determine their risks rsaquo devise a strategy to reduce highest risks
sample failures how would you mitigate rsaquo performance is unacceptable rsaquo product is unusable because its too complex rsaquo customer changes mind about what product does rsaquo developer solves the wrong problem rsaquo product fails in catastrophic way rsaquo competitor beats you into marketplace rsaquo product has reputation for bugs rsaquo development runs out of time and money rsaquo developers rely on platform that turns out bad
5
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 4: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/4.jpg)
risks
4
risk-driven development
Risk = Prob(failure) x Cost(failure)
a strategy rsaquo list failures amp determine their risks rsaquo devise a strategy to reduce highest risks
sample failures how would you mitigate rsaquo performance is unacceptable rsaquo product is unusable because its too complex rsaquo customer changes mind about what product does rsaquo developer solves the wrong problem rsaquo product fails in catastrophic way rsaquo competitor beats you into marketplace rsaquo product has reputation for bugs rsaquo development runs out of time and money rsaquo developers rely on platform that turns out bad
5
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 5: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/5.jpg)
risk-driven development
Risk = Prob(failure) x Cost(failure)
a strategy rsaquo list failures amp determine their risks rsaquo devise a strategy to reduce highest risks
sample failures how would you mitigate rsaquo performance is unacceptable rsaquo product is unusable because its too complex rsaquo customer changes mind about what product does rsaquo developer solves the wrong problem rsaquo product fails in catastrophic way rsaquo competitor beats you into marketplace rsaquo product has reputation for bugs rsaquo development runs out of time and money rsaquo developers rely on platform that turns out bad
5
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 6: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/6.jpg)
doing design
6
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 7: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/7.jpg)
small design upfront
Agilistas deride ldquoBig Design Upfrontrdquo (BDUF)
what about Small Design Upfront rsaquo what isnrsquot worth designing rsaquo can you recover from a bad design rsaquo whatrsquos the cost of design
SDUF strategies rsaquo precise but lightweight notations rsaquo separate concerns amp focus on risks rsaquo avoid implementation bias
7
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 8: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/8.jpg)
be like a beaver
This image is in the public domain
small nibbles big outcome
8
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 9: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/9.jpg)
intuitive vs data-driven design
Google Bing Courtesy of Joshua Porter Used with permission
When a company is filled with engineers it turns to engineering to solve problems Reduce each decision to a simple logic problem Remove all subjectivity and just look at the data Data in your favor OK launch it Data shows negative effects Back to the drawing board And that data eventually becomes a crutch for every decision paralyzing the company and preventing it from making any daring design decisions Doug Bowman
9
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 10: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/10.jpg)
Courtesy of Joshua Porter Used with permission
from Joshua Porter bokardocom 10
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 11: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/11.jpg)
radical design
11
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 12: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/12.jpg)
a TDD guru on sudoku
from httpxprogrammingcomarticlesoksudoku
copy Ron Jeffries All rights reserved This content is excluded from our Creative Commons licenseFor more information see httpocwmitedufairuse
12
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 13: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/13.jpg)
still going after five long blog posts
copy Ron Jeffries All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
Peter Norvig solves in one
see httpnorvigcomsudokuhtml
copy Peter Norvig All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
13
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 14: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/14.jpg)
lessons
risk rsaquo Ron Jeffries focuses on class design rsaquo but real risk is algorithmic
Norvigrsquos advantage rsaquo he knows AI applies standard solution
Walter Vincentirsquos dichotomy rsaquo normal design tweaking parameters rsaquo radical design never done this before
14
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 15: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/15.jpg)
co-evolution
15
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 16: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/16.jpg)
co-evolution
problem space
solution space
16
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 17: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/17.jpg)
UML
Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons
17
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 18: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/18.jpg)
co-evolution in UML
18
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 19: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/19.jpg)
co-evolution in UML
heavy documentationcomplex notations
tool support deferred
19
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 20: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/20.jpg)
the cost of complex tools
20
800
700
600
500
400
300
200
100
0
750
650
550
450
350
250
150
50
P
ages
in D
efin
itio
n
Algo
l-60 19
60
Algo
l-68 19
75
C 19
78
SAS
D 197
9
CLU
1981
JSD 1
983
C++ 1
985
Sche
me 1
986
SML 1
990
OMT 19
91
Z 19
92
Synt
ropy
199
4
Fusio
n 19
94
Java
199
6
UML 1
999
Pasc
al 19
74
Image by MIT OpenCourseWare
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 21: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/21.jpg)
agile
copy the above authors All rights reserved This content is excluded from our CreativeCommons license For more information see httpocwmitedufairuse
21
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 22: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/22.jpg)
co-evolution in agile
22
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 23: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/23.jpg)
co-evolution in agile
baby out with bathwatertodayrsquos orthodoxy
23
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 24: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/24.jpg)
unused
24
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 25: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/25.jpg)
descartesrsquos four rules
The first was never to accept anything for true which I did not clearly know to be such that is to say carefully to avoid precipitancy and prejudice and to comprise nothing more in my judgment than what was presented to my mind so clearly and distinctly as to exclude all ground of doubt
The second to divide each of the difficulties under examination into as many parts as possible and as might be necessary for its adequate solution
The third to conduct my thoughts in such order that by commencing with objects the simplest and easiest to know I might ascend by little and little and as it were step by step to the knowledge of the more complex assigning in thought a certain order even to those objects which in their own nature do not stand in a relation of antecedence and sequence
And the last in every case to make enumerations so complete and reviews so general that I might be assured that nothing was omitted
25
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 26: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/26.jpg)
leibniz on descartesrsquos second rule
ldquoThis rule of Descartes is of little use as long as the art of dividing remains unexplained By dividing his problem into unsuitable parts the inexperienced problem-solver may increase his difficultyrdquo mdashLeibniz Philosophical Writings ed CI Gerhardt Vol 4 p331 1857-1890
26
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 27: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/27.jpg)
norvig on sudoku
Screenshot of Peter Norvigs webpage removed due to copyright restrictions
27
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms
![Page 28: Thoughts on the Software Process - MIT OpenCourseWare · › developers rely on platform that turns out bad . 5. doing design. 6. small design upfront . ... to divide each of the](https://reader034.vdocuments.mx/reader034/viewer/2022042323/5f0dffc07e708231d43d1eb6/html5/thumbnails/28.jpg)
MIT OpenCourseWarehttpocwmitedu
6170 Software StudioSpring 2013
For information about citing these materials or our Terms of Use visit httpocwmiteduterms