A Tale Of Two Systems

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

3

Specific 
The impact of 
design 
design on a 
techniques
system
An entire 
Learn some
software 
ways to 
Our roadmap

design 
improve our 
course
software 
1
designs

4

Learning lessions
Design Town
The Messy 
Metropolis

So what?
Our roadmap

2

5

Our roadmap

So what?

3

6

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

3

12

The Messy 
Metropolis

So what?
Our roadmap

4

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

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

Low quality product
●
The upshot of bad design
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

4

30

Design Town
The Messy 
Metropolis

So what?
Our roadmap

5

31

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 ﬁle 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
controllers
Control

OS/Audio Codecs
Storage
Audio path
management

A B C D E F
OS/Audio codecs

Audio ﬁle 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

5

49

Learning lessions
Design Town
The Messy 
Metropolis

So what?
Our roadmap

6

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

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

“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.quot; 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

A Tale Of Two Systems

Recomendados

Recomendados

Más contenido relacionado

Similar a A Tale Of Two Systems

Similar a A Tale Of Two Systems (20)

Más de QConLondon2008

Más de QConLondon2008 (10)

Último

Último (20)

A Tale Of Two Systems