a tale of two systems

60
1

Upload: qconlondon2008

Post on 12-May-2015

621 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: A Tale Of Two Systems

1

Page 2: A Tale Of Two Systems

2

Page 3: A Tale Of Two Systems

3

Who

is Pe

te?

Who

is Pe

te?

Pete GoodliffePete [email protected]@goodliffe.net

http://www.goodliffe.nethttp://www.goodliffe.net

Page 4: A Tale Of Two Systems

4

Our r

oadm

apOu

r roa

dmap

Specificdesign

techniques

Anentiresoftwaredesigncourse

Theimpactofdesignonasystem

Learnsomewaystoimproveoursoftwaredesigns 1

Page 5: A Tale Of Two Systems

5

Our r

oadm

apOu

r roa

dmap

Sowhat?

DesignTown

TheMessyMetropolis

Learninglessions

2

Page 6: A Tale Of Two Systems

6

Our r

oadm

apOu

r roa

dmap

Sowhat?

3

Page 7: A Tale Of Two Systems

7

Sowhat?Sowhat?

Page 8: A Tale Of Two Systems

8

So w

hat?

So w

hat?

Page 9: A Tale Of Two Systems

9

So w

hat?

So w

hat?

Page 10: A Tale Of Two Systems

10

● Ease of modificationEase of modification● Ease of extensionEase of extension● Fit for purposeFit for purpose● Ease of documentationEase of documentation

Wha

t has

desig

n don

e for

us?

Wha

t has

desig

n don

e for

us?

● Design quality is a Design quality is a sink or swimsink or swim issue for issue for software projectssoftware projects

● Some people/teams are inherently Some people/teams are inherently better at design than othersbetter at design than others

Page 11: A Tale Of Two Systems

11

● Effects within softwareEffects within software– Software qualitySoftware quality– Developer sanityDeveloper sanity

● Influences outside softwareInfluences outside software– Success of projectSuccess of project– Team structureTeam structure– MoraleMorale– Company successCompany success

Desig

n mat

ters

Desig

n mat

ters

Page 12: A Tale Of Two Systems

12

Our r

oadm

apOu

r roa

dmap

Sowhat?

3

Page 13: A Tale Of Two Systems

13

Our r

oadm

apOu

r roa

dmap

Sowhat?

TheMessyMetropolis

4

Page 14: A Tale Of Two Systems

14

● These are comparable systemsThese are comparable systems● Similar sizeSimilar size● Both Linux-basedBoth Linux-based● ““Embedded” applicationsEmbedded” applications● Audio productsAudio products● C++C++● Developed by “experienced” Developed by “experienced”

programmersprogrammers● Programmers were designersProgrammers were designers● Names have been changed to protect the Names have been changed to protect the

innocent/guiltyinnocent/guiltyA tal

e of t

wo sy

stem

sA t

ale o

f two

syst

ems

Page 15: A Tale Of Two Systems

15

TheMessyTheMessyMetropolisMetropolis

Page 16: A Tale Of Two Systems

16

● A project well under way when I joinedA project well under way when I joined● ““Modern” C++ codebase, a few years oldModern” C++ codebase, a few years old● Ouch!Ouch!● Warning signs:Warning signs:

– Code took a fantastically long time to learnCode took a fantastically long time to learn– No obvious routes into the systemNo obvious routes into the system– It was (broadly) clear what the product did, It was (broadly) clear what the product did,

but no one explained how it did itbut no one explained how it did it– Actually getting the code, and getting it to Actually getting the code, and getting it to

build was a rite of passagebuild was a rite of passage

First

cont

act

First

cont

act

Page 17: A Tale Of Two Systems

17

● Micro-level problems:Micro-level problems:– Messy, inconsistent code, with no styleMessy, inconsistent code, with no style– Badly put togetherBadly put together– No unifying conceptsNo unifying concepts– Far to many bad code smellsFar to many bad code smells

War

ning

sign

sW

arni

ng si

gns

Page 18: A Tale Of Two Systems

18

● Macro-level problems:Macro-level problems:– Control flew around the system in Control flew around the system in

unfathomable waysunfathomable ways– Data rarely kept near where it was usedData rarely kept near where it was used– Many baroque caching layers to mitigate thisMany baroque caching layers to mitigate this

War

ning

sign

sW

arni

ng si

gns

Page 19: A Tale Of Two Systems

19

● No one had a complete picture of systemNo one had a complete picture of system● No one actually knew how it worked!No one actually knew how it worked!

– A combination of luck and heroic A combination of luck and heroic maintenance programmersmaintenance programmers

● People only knew their own small areasPeople only knew their own small areas● Naturally there was no documentationNaturally there was no documentation

● Town planning disaster!Town planning disaster!● We needed a mapWe needed a map

War

ning

sign

sW

arni

ng si

gns

Page 20: A Tale Of Two Systems

20

The m

apTh

e map

Page 21: A Tale Of Two Systems

21

The m

apTh

e map

Page 22: A Tale Of Two Systems

22

The m

apTh

e map

Page 23: A Tale Of Two Systems

23

● Design problems went directly to the topDesign problems went directly to the top– Development processDevelopment process– Company cultureCompany culture

● Code grown “organically” over timeCode grown “organically” over time● Had been given no architectural designHad been given no architectural design

● A system never has A system never has nono design design

● Understandable given company historyUnderstandable given company history

Softw

are a

rche

olog

ySo

ftwar

e arc

heol

ogy

Page 24: A Tale Of Two Systems

24

● Hard to comprehend systemHard to comprehend system● Practically impossible to modifyPractically impossible to modify● Bad design encouraged further bad designBad design encouraged further bad design

– Paths of least resistancePaths of least resistance● New recruits stunned by complexityNew recruits stunned by complexity

– Very high staff turnoverVery high staff turnover● System components not cohesiveSystem components not cohesive

– Grab-bags of unrelated functionalityGrab-bags of unrelated functionality– Hard to determine Hard to determine whywhy a component existed a component existed– Hard to work out Hard to work out wherewhere particular particular

functionality was implementedfunctionality was implemented● Bugfixing nightmare!Bugfixing nightmare!Co

nseq

uenc

es: D

esig

nCo

nseq

uenc

es: D

esig

n

Page 25: A Tale Of Two Systems

25

● Functionality and data in the wrong placeFunctionality and data in the wrong place– ““Core services” not in the coreCore services” not in the core– Why? Why? Team dynamicsTeam dynamics! (Empire building)! (Empire building)

● No clear layeringNo clear layering– Bidirectional couplingBidirectional coupling– No “bottom” or “hub” or the systemNo “bottom” or “hub” or the system

● ⇒⇒ tight couplingtight coupling● Low-level Low-level testing impossibletesting impossible

– No class unit testsNo class unit tests– No component testsNo component tests

Cons

eque

nces

: Lay

erin

gCo

nseq

uenc

es: L

ayer

ing

Page 26: A Tale Of Two Systems

26

● Design problems Design problems fed into code problemsfed into code problems– Like no one bothered with design, no one Like no one bothered with design, no one

bothered with code standardbothered with code standard– DuplicationDuplication– No common librariesNo common libraries– No common idiomsNo common idioms– No naming conventionsNo naming conventions– No common build systemNo common build system

● Why?Why?– More software archeology...More software archeology...– An accidental conurbationAn accidental conurbation– Know what you're designingKnow what you're designingCo

nseq

uenc

es: C

ode

Cons

eque

nces

: Cod

e

Page 27: A Tale Of Two Systems

27

● Problems Problems spilled outspilled out beyond development beyond development teamteam– Slow development cycleSlow development cycle– Support engineersSupport engineers– External protocolExternal protocol– Intra-company politics (marketing, sales, Intra-company politics (marketing, sales,

manufacturing)manufacturing)

Cons

eque

nces

: Tea

mCo

nseq

uenc

es: T

eam

Page 28: A Tale Of Two Systems

28

● It headed in a downward spiralIt headed in a downward spiral● Very uneconomical to maintainVery uneconomical to maintain● Did not fulfil business objectivesDid not fulfil business objectives● Thrown awayThrown away● Rewritten in C# on WindowsRewritten in C# on Windows

Whe

re is

it no

w?W

here

is it

now?

Page 29: A Tale Of Two Systems

29

● Low quality productLow quality product● Inflexible systemInflexible system

– Can't accommodate changeCan't accommodate change– Can't add new functionalityCan't add new functionality

● Pervasive code problemsPervasive code problems● Infrequent releasesInfrequent releases● Staffing problemsStaffing problems● Messy internal politicsMessy internal politics● Lack of successLack of success● Many painful headaches and late nightsMany painful headaches and late nightsTh

e ups

hot o

f bad

desig

nTh

e ups

hot o

f bad

desig

n

Page 30: A Tale Of Two Systems

30

Our r

oadm

apOu

r roa

dmap

Sowhat?

TheMessyMetropolis

4

Page 31: A Tale Of Two Systems

31

Our r

oadm

apOu

r roa

dmap

Sowhat?

DesignTown

TheMessyMetropolis

5

Page 32: A Tale Of Two Systems

32

DesignTownDesignTown

Page 33: A Tale Of Two Systems

33

● Involved from very startInvolved from very start● New team of capable programmersNew team of capable programmers

– Small teamSmall team– Flat structureFlat structure– No rivalryNo rivalry

● Clear roadmapClear roadmap– Initial productInitial product– Future functionalityFuture functionality

● XP developmentXP development

First

cont

act

First

cont

act

Page 34: A Tale Of Two Systems

34

● XP and design?XP and design?

● YAGNIYAGNI● SpikesSpikes

eXtre

me P

rogr

amm

ing

eXtre

me P

rogr

amm

ing

Page 35: A Tale Of Two Systems

35

● Started with design!Started with design!● NotNot a big up-front design a big up-front design● Identified main areas of functionalityIdentified main areas of functionality● Initial architectureInitial architecture● Core threading modelsCore threading models

First

step

sFir

st st

eps Control Components

User Interface

Audio Path

OS/Audio Codecs

Page 36: A Tale Of Two Systems

36

● Audio path as sub-architectureAudio path as sub-architecture● Pipe and filterPipe and filter● Product configuration determines Product configuration determines

individual audio pathindividual audio path

First

step

sFir

st st

eps

A B C D E F

Audio file Audio hardwareControl Components

User Interface

Audio Path

OS/Audio Codecs

Page 37: A Tale Of Two Systems

37

● Other early choices:Other early choices:– Supporting librariesSupporting libraries– Top-level file structureTop-level file structure– NamingNaming– ““House” presentation styleHouse” presentation style– Coding idiomsCoding idioms– Choice of unit test frameworkChoice of unit test framework– InfrastructureInfrastructure

● Source controlSource control● Build systemBuild system● Continuous integrationContinuous integration

● These influenced design decisionsThese influenced design decisionsFirst

step

sFir

st st

eps

Page 38: A Tale Of Two Systems

38

● Helped to locate new functionalityHelped to locate new functionality– With clear system overview...With clear system overview...– New units of functionality consistently added New units of functionality consistently added

the the the right placethe right place– Easy to find where existing functionality Easy to find where existing functionality

implementedimplemented– Easy to locate/fix bugsEasy to locate/fix bugs– Not always convenientNot always convenient

● Made programmers work harderMade programmers work harder● Payoff: easier life laterPayoff: easier life later

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 39: A Tale Of Two Systems

39

● Entire system was consistentEntire system was consistent– Every decision was taken in the context of Every decision was taken in the context of

the whole designthe whole design– Done intentionallyDone intentionally– Design always in view:Design always in view:

● All code produced fitted the designAll code produced fitted the design

– Over entire life of system, things followed Over entire life of system, things followed original designoriginal design

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 40: A Tale Of Two Systems

40

● Elegance at top level fed down to the Elegance at top level fed down to the lower levelslower levels– At lowest level, code uniform and neatAt lowest level, code uniform and neat– Helped byHelped by

● Pair programmingPair programming● Code reviewsCode reviews● Code standardsCode standards

– No unusual surprisesNo unusual surprises

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 41: A Tale Of Two Systems

41

● New areas of functionality appearedNew areas of functionality appeared– Not a problemNot a problem– Design (like code) malleableDesign (like code) malleable– Nothing is set in stoneNothing is set in stone– Design must be changed when requiredDesign must be changed when required– Encouraged Encouraged simple designsimple design– Consequence:Consequence:

● Code could grow rapidlyCode could grow rapidly● Code could maintain good internal structureCode could maintain good internal structure

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 42: A Tale Of Two Systems

42

● (Unit) test everything(Unit) test everything– ChangeChange sections of software without breaking sections of software without breaking

everything elseeverything else● Design town had major design changesDesign town had major design changes

– Shaping of the code designShaping of the code design● Enforce good code structureEnforce good code structure● Loosely coupled: construct in a test harnessLoosely coupled: construct in a test harness● CohesiveCohesive

– Encouraged good APIsEncouraged good APIs

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 43: A Tale Of Two Systems

43

● Quality controlQuality control– Pair programmingPair programming– Code reviewsCode reviews– Reviews ensured changes did not sully designReviews ensured changes did not sully design

● Programmers took responsibility forProgrammers took responsibility for the designthe design

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 44: A Tale Of Two Systems

44

● Pragmatic approach to designPragmatic approach to design– Deadlines lead to corner-cuttingDeadlines lead to corner-cutting– Technical debtTechnical debt– Scheduled for later revisionScheduled for later revision

● TimescalesTimescales worked in favour worked in favour– Not too longNot too long– Not too shortNot too short

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 45: A Tale Of Two Systems

45

● Team dynamics followed code designTeam dynamics followed code design– No one “owned” codeNo one “owned” code– Everyone expected to write high-quality codeEveryone expected to write high-quality code– Closely co-operating colleaguesClosely co-operating colleagues– Conway's LawConway's Law

● Design was sufficiently well documentedDesign was sufficiently well documented– Architecture overviewArchitecture overview– Code as documentationCode as documentation

● Naming conventionsNaming conventions● Structure (namespaces, nested classes, Structure (namespaces, nested classes,

enums, etc)enums, etc)

– DoxygenDoxygenThe s

tory

unfo

lds

The s

tory

unfo

lds

Page 46: A Tale Of Two Systems

46

● New team members could enter project New team members could enter project easilyeasily

● Code still Code still enjoyableenjoyable to work with to work with– Low turnover of membersLow turnover of members– Programmers taking ownershipProgrammers taking ownership

The s

tory

unfo

lds

The s

tory

unfo

lds

Page 47: A Tale Of Two Systems

47

One W

e Mad

e Ear

lier

One W

e Mad

e Ear

lier

A B C D E F

Audio file Audio hardware

Control Components

User Interface

Audio Path

OS/Audio Codecs

Audio pathStoragemanagement

User Interface

Control

OS/Audio codecs

Externalcontrollers

Page 48: A Tale Of Two Systems

48

● Still in useStill in use● Still being developedStill being developed● Still changingStill changing● Not perfectNot perfect

Whe

re is

it no

w?W

here

is it

now?

Page 49: A Tale Of Two Systems

49

Our r

oadm

apOu

r roa

dmap

Sowhat?

DesignTown

TheMessyMetropolis

5

Page 50: A Tale Of Two Systems

50

Our r

oadm

apOu

r roa

dmap

Sowhat?

DesignTown

TheMessyMetropolis

Learninglessions

6

Page 51: A Tale Of Two Systems

51

● Design mattersDesign matters– It can go spectacularly wrongIt can go spectacularly wrong– It can go spectacularly rightIt can go spectacularly right

● You've got to design on purposeYou've got to design on purpose– This does not mean a big up-front designThis does not mean a big up-front design

● Good designGood design– Leads to better codeLeads to better code– Leads to better teamsLeads to better teams– Leads to successLeads to success

The m

oral

of th

e sto

ryTh

e mor

al of

the s

tory

Page 52: A Tale Of Two Systems

52

● Good design comes from:Good design comes from:– Actually Actually doingdoing up-front design (as much as up-front design (as much as

required)required)– Quality and experience of designersQuality and experience of designers– Keeping design in view at all timesKeeping design in view at all times– Team being given/talking responsibilityTeam being given/talking responsibility– Not being afraid of changing designNot being afraid of changing design– Team:Team:

● Having the right people on the teamHaving the right people on the team● Size of the teamSize of the team● Health of working relationshipsHealth of working relationships

– Making decisions at the right timeMaking decisions at the right time– Good project managementGood project managementTh

e mor

al of

the s

tory

The m

oral

of th

e sto

ry

Page 53: A Tale Of Two Systems

53

FinFin

Page 54: A Tale Of Two Systems

54

Your

turn

Your

turn

Page 55: A Tale Of Two Systems

55

Your

turn

Your

turn

● What's the What's the bestbest system you've ever seen? system you've ever seen?– What have you learnt from it?What have you learnt from it?– What were the consequences of this design:What were the consequences of this design:

● Inside codeInside code● Outside codeOutside code

● What's the What's the worstworst system you've ever seen system you've ever seen– What have you learnt from it?What have you learnt from it?– What were the consequences of this design:What were the consequences of this design:

● Inside codeInside code● Outside codeOutside code

Page 56: A Tale Of Two Systems

56

Epilo

gue

Epilo

gue

Page 57: A Tale Of Two Systems

57

The b

ook

The b

ook

. . . bu

y it n

ow!

. . . bu

y it n

ow!

““Its Its usefuluseful andand funfun and it'll and it'll make you a better make you a better programmer.” programmer.” Jez HigginsJez Higgins “A “A goldmine of informationgoldmine of informationthat every professional that every professional software developer should be software developer should be aware of.” aware of.” Tim PenheyTim Penhey “A “A terrific resourceterrific resource for for developers wanting to learn or developers wanting to learn or teach good coding practices ... teach good coding practices ... deserves a place on the deserves a place on the bookshelf.” bookshelf.” Frazzled Dad blog Frazzled Dad blog ““A A unique and practicalunique and practicalguide to being a professional guide to being a professional programmer in the modern programmer in the modern workplace.” workplace.” Andrew BurrowsAndrew Burrows““ReadableReadable, , engagingengaging, and , and even even funnyfunny ... It's the book I ... It's the book I wish I'd had when I started wish I'd had when I started work as a programmer." work as a programmer." Steve Steve LoveLove “A “A 'must read''must read' for any for any programmer who wants to be programmer who wants to be a better programmer” a better programmer” Linux Linux TutorialTutorial “This is “This is exactlyexactly the the kind of book you should give kind of book you should give raw recruits.”raw recruits.” Jon Jagger Jon Jagger

Page 58: A Tale Of Two Systems

58

Any q

uest

ions

?An

y que

stio

ns?

Page 59: A Tale Of Two Systems

59© 2008 Pete Goodliffe. All rights reserved. No part of this document may be reproduced without the author's prior permission.© 2008 Pete Goodliffe. All rights reserved. No part of this document may be reproduced without the author's prior permission.

Page 60: A Tale Of Two Systems

60

Version info:Version info:

Slides version:Slides version: 0.50.5

Last updated: Last updated: 2008-03-122008-03-12

Copyright:Copyright: © 2008 Pete Goodliffe© 2008 Pete Goodliffe