1

2
 Pete Goodliffe
pete@goodliffe.net
http://www.goodliffe.net
Who is Pete?

3
 The
impact
of
 Specific

design
on
a
 design

system techniques

Learn
some An
entire

ways
to
 software

Our roadmap

improve
our
 design

software
 course
designs 1

4
 Learning
lessions
Design
Town
The
Messy

Metropolis

So
what?
Our roadmap

5
 Our roadmap

So
what?

6
So
what?

7
 So what?

8
 So what?

9
What has design done for us?
● Ease of modification
● Ease of extension
●
Fit for purpose
● Ease of documentation

● Design quality is a sink or swim issue for

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

10
 ● Effects within software
– Software quality
– Developer sanity
● Influences outside software
– Success of project
– Team structure
Design matters

– Morale
– Company success

11
 So
what?
Our roadmap

12
 The
Messy

Metropolis

So
what?
Our roadmap

13
 ● These are comparable systems
● Similar size
●
Both Linux-based
“Embedded” applications
A tale of two systems

● Audio products
● C++
● Developed by “experienced”
programmers
● Programmers were designers
● Names have been changed to protect the
innocent/guilty
14
The
Messy

Metropolis

15
 ● A project well under way when I joined
● “Modern” C++ codebase, a few years old
●
Ouch!
● Warning signs:
– Code took a fantastically long time to learn
– No obvious routes into the system
– It was (broadly) clear what the product did,
First contact

but no one explained how it did it

– Actually getting the code, and getting it to
build was a rite of passage

16
 ● Micro-level problems:
– Messy, inconsistent code, with no style
– Badly put together
– No unifying concepts
– Far to many bad code smells
Warning signs

17
 ● Macro-level problems:
– Control flew around the system in
unfathomable ways
– Data rarely kept near where it was used
– Many baroque caching layers to mitigate this
Warning signs

18
 ● No one had a complete picture of system
● No one actually knew how it worked!
– A combination of luck and heroic
maintenance programmers
● People only knew their own small areas
● Naturally there was no documentation
Warning signs

● Town planning disaster!

●
We needed a map

19
 The map

20
 The map

21
 The map

22
 ● Design problems went directly to the top
– Development process
– Company culture
● Code grown “organically” over time
Software archeology

●
Had been given no architectural design

●
A system never has no design

● Understandable given company history

23
 ● Hard to comprehend system
● Practically impossible to modify
●
Bad design encouraged further bad design
Consequences: Design

– Paths of least resistance

● New recruits stunned by complexity
– Very high staff turnover
●
System components not cohesive
– Grab-bags of unrelated functionality
– Hard to determine why a component existed
– Hard to work out where particular
functionality was implemented
●
Bugfixing nightmare!
24
 ● Functionality and data in the wrong place
– “Core services” not in the core
Consequences: Layering
– Why? Team dynamics! (Empire building)
● No clear layering
– Bidirectional coupling
– No “bottom” or “hub” or the system
● tight coupling
●
Low-level testing impossible
– No class unit tests
– No component tests

25
 ● Design problems fed into code problems
– Like no one bothered with design, no one
bothered with code standard
– Duplication
Consequences: Code

– No common libraries
– No common idioms
– No naming conventions
– No common build system
● Why?
– More software archeology...
– An accidental conurbation
– Know what you're designing
26
 ● Problems spilled out beyond development
team
– Slow development cycle
– Support engineers
Consequences: Team

– External protocol
– Intra-company politics (marketing, sales,
manufacturing)

27
 ● It headed in a downward spiral
● Very uneconomical to maintain
●
Did not fulfil business objectives
● Thrown away
● Rewritten in C# on Windows
Where is it now?

28
The upshot of bad design ●
Low quality product
● Inflexible system
– Can't accommodate change
– Can't add new functionality
● Pervasive code problems
● Infrequent releases
● Staffing problems
● Messy internal politics
●
Lack of success
●
Many painful headaches and late nights
29
 The
Messy

Metropolis

So
what?
Our roadmap

30
 Design
Town
The
Messy

Metropolis

So
what?
Our roadmap

31
Design
Town

32
 ● Involved from very start
● New team of capable programmers
– Small team
– Flat structure
– No rivalry
● Clear roadmap
– Initial product
First contact

– Future functionality
● XP development

33
 ● XP and design?

●
YAGNI
eXtreme Programming

● Spikes

34
 ● Started with design!
● Not a big up-front design
●
Identified main areas of functionality
● Initial architecture
● Core threading models
User Interface
First steps

Control Components

Audio Path

OS/Audio Codecs

35
 ● Audio path as sub-architecture
● Pipe and filter
●
Product configuration determines
individual audio path

User Interface
A B C D E F
First steps

Control Components
Audio file Audio hardware

Audio Path

OS/Audio Codecs

36
 ● Other early choices:
– Supporting libraries
– Top-level file structure
– Naming
– “House” presentation style
– Coding idioms
– Choice of unit test framework
– Infrastructure
First steps

●
Source control
● Build system
●
Continuous integration

●
These influenced design decisions
37
 ● Helped to locate new functionality
– With clear system overview...
– New units of functionality consistently added
the the right place
– Easy to find where existing functionality
implemented
The story unfolds

– Easy to locate/fix bugs

– Not always convenient
●
Made programmers work harder
●
Payoff: easier life later

38
 ● Entire system was consistent
– Every decision was taken in the context of
the whole design
– Done intentionally
– Design always in view:
All code produced fitted the design
The story unfolds

– Over entire life of system, things followed

original design

39
 ● Elegance at top level fed down to the
lower levels
– At lowest level, code uniform and neat
– Helped by
●
Pair programming
●
Code reviews
The story unfolds

● Code standards
– No unusual surprises

40
 ● New areas of functionality appeared
– Not a problem
– Design (like code) malleable
– Nothing is set in stone
– Design must be changed when required
The story unfolds

– Encouraged simple design

– Consequence:
●
Code could grow rapidly
●
Code could maintain good internal structure

41
 ● (Unit) test everything
– Change sections of software without breaking
everything else
●
Design town had major design changes
– Shaping of the code design
●
Enforce good code structure
The story unfolds

● Loosely coupled: construct in a test harness

● Cohesive
– Encouraged good APIs

42
 ● Quality control
– Pair programming
– Code reviews
– Reviews ensured changes did not sully design
The story unfolds

● Programmers took responsibility for

the design

43
 ● Pragmatic approach to design
– Deadlines lead to corner-cutting
– Technical debt
– Scheduled for later revision
The story unfolds

● Timescales worked in favour

– Not too long
– Not too short

44
 ● Team dynamics followed code design
– No one “owned” code
– Everyone expected to write high-quality code
– Closely co-operating colleagues
– Conway's Law
The story unfolds

● Design was sufficiently well documented

– Architecture overview
– Code as documentation
● Naming conventions
● Structure (namespaces, nested classes,
enums, etc)
– Doxygen
45
 ● New team members could enter project
easily

● Code still enjoyable to work with

– Low turnover of members
The story unfolds

– Programmers taking ownership

46
 User Interface

Control Components
User Interface
One We Made Earlier

External
Audio Path
Control controllers

OS/Audio Codecs
Storage
Audio path
management

A B C D E F
OS/Audio codecs

Audio file Audio hardware

47
 ● Still in use
● Still being developed
●
Still changing
● Not perfect
Where is it now?

48
 Design
Town
The
Messy

Metropolis

So
what?
Our roadmap

49
 Learning
lessions
Design
Town
The
Messy

Metropolis

So
what?
Our roadmap

50
 ● Design matters
– It can go spectacularly wrong
– It can go spectacularly right
You've got to design on purpose
The moral of the story

– This does not mean a big up-front design

●
Good design
– Leads to better code
– Leads to better teams
– Leads to success

51
 ● Good design comes from:
– Actually doing up-front design (as much as
required)
– Quality and experience of designers
The moral of the story

– Keeping design in view at all times

– Team being given/talking responsibility
– Not being afraid of changing design
– Team:
●
Having the right people on the team
●
Size of the team
● Health of working relationships
– Making decisions at the right time
– Good project management
52
Fin

53
 Your turn

54
 ● What's the best system you've ever seen?
– What have you learnt from it?
– What were the consequences of this design:
● Inside code
● Outside code
● What's the worst system you've ever seen
Your turn

– What have you learnt from it?

– What were the consequences of this design:
● Inside code
●
Outside code
55
 Epilogue

56
 “Its useful and fun and it'll
make you a better
programmer.” Jez Higgins “A
goldmine of information
that every professional
software developer should be
aware of.” Tim Penhey “A
terrific resource for
developers wanting to learn or
teach good coding practices ...
. . . buy it now!

deserves a place on the

bookshelf.” Frazzled Dad blog
“A unique and practical
guide to being a professional
programmer in the modern
workplace.” Andrew Burrows
“Readable, engaging, and
even funny ... It's the book I
wish I'd had when I started
work as a programmer." Steve
Love “A 'must read' for any
The book

programmer who wants to be

a better programmer” Linux
Tutorial “This is exactly the
kind of book you should give
raw recruits.” Jon Jagger

57
 Any questions?

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

Slides version: 0.5

Last updated: 2008-03-12
Copyright: © 2008 Pete Goodliffe

60