Download - Pete Goodliffe A Tale Of Two Systems
1
2
3
Who
is Pe
te?
Who
is Pe
te?
Pete GoodliffePete [email protected]@goodliffe.net
http://www.goodliffe.nethttp://www.goodliffe.net
4
Our r
oadm
apOu
r roa
dmap
Specificdesign
techniques
Anentiresoftwaredesigncourse
Theimpactofdesignonasystem
Learnsomewaystoimproveoursoftwaredesigns 1
5
Our r
oadm
apOu
r roa
dmap
Sowhat?
DesignTown
TheMessyMetropolis
Learninglessions
2
6
Our r
oadm
apOu
r roa
dmap
Sowhat?
3
7
Sowhat?Sowhat?
8
So w
hat?
So w
hat?
9
So w
hat?
So w
hat?
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
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
12
Our r
oadm
apOu
r roa
dmap
Sowhat?
3
13
Our r
oadm
apOu
r roa
dmap
Sowhat?
TheMessyMetropolis
4
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
15
TheMessyTheMessyMetropolisMetropolis
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
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
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
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
20
The m
apTh
e map
21
The m
apTh
e map
22
The m
apTh
e map
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
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
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
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
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
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?
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
30
Our r
oadm
apOu
r roa
dmap
Sowhat?
TheMessyMetropolis
4
31
Our r
oadm
apOu
r roa
dmap
Sowhat?
DesignTown
TheMessyMetropolis
5
32
DesignTownDesignTown
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
34
● XP and design?XP and design?
● YAGNIYAGNI● SpikesSpikes
eXtre
me P
rogr
amm
ing
eXtre
me P
rogr
amm
ing
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
49
Our r
oadm
apOu
r roa
dmap
Sowhat?
DesignTown
TheMessyMetropolis
5
50
Our r
oadm
apOu
r roa
dmap
Sowhat?
DesignTown
TheMessyMetropolis
Learninglessions
6
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
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
53
FinFin
54
Your
turn
Your
turn
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
56
Epilo
gue
Epilo
gue
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
58
Any q
uest
ions
?An
y que
stio
ns?
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.
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