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




      ...
The
impact
of
      Specific

              design
on
a
         design

              system           techniques

      ...
Learning
lessions
                      Design
Town
                              The
Messy

                             ...
Our roadmap




               So
what?


           3




6
So
what?



           7
So what?




8
So what?




9
What has design done for us?
                               ●   Ease of modification
                               ●   Ea...
●   Effects within software
                     –   Software quality
                     –   Developer sanity
          ...
So
what?
Our roadmap




                         3




                             12
The
Messy

                         Metropolis

              So
what?
Our roadmap




                                   ...
●   These are comparable systems
                        ●   Similar size
                        ●
                      ...
The
Messy

Metropolis



             15
●   A project well under way when I joined
                ●   “Modern” C++ codebase, a few years old
                ●
  ...
●   Micro-level problems:
                    –   Messy, inconsistent code, with no style
                    –   Badly pu...
●   Macro-level problems:
                    –   Control flew around the system in
                        unfathomable w...
●   No one had a complete picture of system
                ●   No one actually knew how it worked!
                    – ...
The map




20
The map




21
The map




22
●   Design problems went directly to the top
                          –   Development process
                          –...
●   Hard to comprehend system
                       ●   Practically impossible to modify
                       ●
       ...
●   Functionality and data in the wrong place
                             –   “Core services” not in the core
Consequence...
●   Design problems fed into code problems
                         –   Like no one bothered with design, no one
         ...
●   Problems spilled out beyond development
                         team
                         –   Slow development cy...
●   It headed in a downward spiral
                   ●   Very uneconomical to maintain
                   ●
             ...
The upshot of bad design   ●
                               Low quality product
                           ●   Inflexible ...
The
Messy

                         Metropolis

              So
what?
Our roadmap




                                   ...
Design
Town
                             The
Messy

                             Metropolis

              So
what?
Our ro...
Design
Town



              32
●   Involved from very start
                ●   New team of capable programmers
                    –   Small team
      ...
●   XP and design?

                      ●
                          YAGNI
eXtreme Programming

                      ●  ...
●   Started with design!
              ●   Not a big up-front design
              ●
                  Identified main are...
●   Audio path as sub-architecture
                ●   Pipe and filter
                ●
                    Product confi...
●   Other early choices:
                  –   Supporting libraries
                  –   Top-level file structure
       ...
●   Helped to locate new functionality
                        –   With clear system overview...
                        –...
●   Entire system was consistent
                        –   Every decision was taken in the context of
                  ...
●   Elegance at top level fed down to the
                        lower levels
                        –   At lowest level...
●   New areas of functionality appeared
                        –   Not a problem
                        –   Design (like...
●   (Unit) test everything
                        –   Change sections of software without breaking
                      ...
●   Quality control
                        –   Pair programming
                        –   Code reviews
                ...
●   Pragmatic approach to design
                        –   Deadlines lead to corner-cutting
                        –   ...
●   Team dynamics followed code design
                        –   No one “owned” code
                        –   Everyon...
●   New team members could enter project
                        easily

                    ●   Code still enjoyable to w...
User Interface


                                                Control Components
                                      ...
●   Still in use
                   ●   Still being developed
                   ●
                       Still changing
 ...
Design
Town
                             The
Messy

                             Metropolis

              So
what?
Our ro...
Learning
lessions
                      Design
Town
                              The
Messy

                             ...
●   Design matters
                             –   It can go spectacularly wrong
                             –   It can ...
●   Good design comes from:
                             –   Actually doing up-front design (as much as
                  ...
Fin


      53
Your turn




54
●   What's the best system you've ever seen?
                –   What have you learnt from it?
                –   What we...
Epilogue




56
“Its useful and fun and it'll
                     make       you     a     better
                     programmer.” Jez H...
Any questions?




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


Slides version:   0.5
Last updated:     2008-03-12
Copyright:        © 2008 Pete Goodliffe




           ...
Upcoming SlideShare
Loading in...5
×

Pete Goodliffe A Tale Of Two Systems

3,000

Published on

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,000
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Pete Goodliffe A Tale Of Two Systems

  1. 1. 1
  2. 2. 2
  3. 3. Pete Goodliffe pete@goodliffe.net http://www.goodliffe.net Who is Pete? 3
  4. 4. 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
  5. 5. Learning
lessions Design
Town The
Messy
 Metropolis So
what? Our roadmap 2 5
  6. 6. Our roadmap So
what? 3 6
  7. 7. So
what? 7
  8. 8. So what? 8
  9. 9. So what? 9
  10. 10. 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
  11. 11. ● Effects within software – Software quality – Developer sanity ● Influences outside software – Success of project – Team structure Design matters – Morale – Company success 11
  12. 12. So
what? Our roadmap 3 12
  13. 13. The
Messy
 Metropolis So
what? Our roadmap 4 13
  14. 14. ● 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
  15. 15. The
Messy
 Metropolis 15
  16. 16. ● 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
  17. 17. ● Micro-level problems: – Messy, inconsistent code, with no style – Badly put together – No unifying concepts – Far to many bad code smells Warning signs 17
  18. 18. ● 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
  19. 19. ● 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
  20. 20. The map 20
  21. 21. The map 21
  22. 22. The map 22
  23. 23. ● 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
  24. 24. ● 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
  25. 25. ● 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
  26. 26. ● 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
  27. 27. ● Problems spilled out beyond development team – Slow development cycle – Support engineers Consequences: Team – External protocol – Intra-company politics (marketing, sales, manufacturing) 27
  28. 28. ● 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
  29. 29. 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
  30. 30. The
Messy
 Metropolis So
what? Our roadmap 4 30
  31. 31. Design
Town The
Messy
 Metropolis So
what? Our roadmap 5 31
  32. 32. Design
Town 32
  33. 33. ● 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
  34. 34. ● XP and design? ● YAGNI eXtreme Programming ● Spikes 34
  35. 35. ● 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
  36. 36. ● 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
  37. 37. ● 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
  38. 38. ● 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
  39. 39. ● 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
  40. 40. ● 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
  41. 41. ● 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
  42. 42. ● (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
  43. 43. ● Quality control – Pair programming – Code reviews – Reviews ensured changes did not sully design The story unfolds ● Programmers took responsibility for the design 43
  44. 44. ● 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
  45. 45. ● 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
  46. 46. ● New team members could enter project easily ● Code still enjoyable to work with – Low turnover of members The story unfolds – Programmers taking ownership 46
  47. 47. 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
  48. 48. ● Still in use ● Still being developed ● Still changing ● Not perfect Where is it now? 48
  49. 49. Design
Town The
Messy
 Metropolis So
what? Our roadmap 5 49
  50. 50. Learning
lessions Design
Town The
Messy
 Metropolis So
what? Our roadmap 6 50
  51. 51. ● 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
  52. 52. ● 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
  53. 53. Fin 53
  54. 54. Your turn 54
  55. 55. ● 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
  56. 56. Epilogue 56
  57. 57. “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
  58. 58. Any questions? 58
  59. 59. © 2008 Pete Goodliffe. All rights reserved. No part of this document may be reproduced without the author's prior permission. 59
  60. 60. Version info: Slides version: 0.5 Last updated: 2008-03-12 Copyright: © 2008 Pete Goodliffe 60
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×