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

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

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

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

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

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

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

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

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

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

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

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

problem space

solution space

16

UML

Image of UML diagrams removed due to copyright restrictionsReference Illustration by Kishorekumar 62 on Wikimedia Commons

17

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 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

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

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

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

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

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

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

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