The not so-big software design

643 views
599 views

Published on

Opening keynote for 2013 wroc_love.rb, Wrocław, Poland.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
643
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The not so-big software design

  1. 1. Good morning wroc_love.rb! 1Tuesday, 12 March, 13
  2. 2. The reputation of a speaker varies with the square of the distance travelled to speak. 2Tuesday, 12 March, 13
  3. 3. The reputation of a speaker varies with the square of the distance travelled to speak. 2Tuesday, 12 March, 13
  4. 4. the preamble... 3Tuesday, 12 March, 13
  5. 5. THE NOT-SO-BIG HOUSE 4Tuesday, 12 March, 13
  6. 6. Sarah Susanka • Residential Architect • Author, "The Not-So-Big- House" and "The Not-So- Big Life" amongst others 5Tuesday, 12 March, 13
  7. 7. THE NOT-SO-BIG HOUSE Part I: The Problem 6Tuesday, 12 March, 13
  8. 8. What is "Not-So-Big?" • Single family dwellings • Emphasis on what is unique to each owner • Form follows functionality • Says "no" to popular conception of value: 2,400 sq. ft. for the price of 4,000 7Tuesday, 12 March, 13
  9. 9. 2,400 sq. ft. for the price of 4,000!? Why? 8Tuesday, 12 March, 13
  10. 10. 9Tuesday, 12 March, 13
  11. 11. The Big House • 4,000 sq. ft. or more. • Vaulted and double-height spaces • Boxes for people • Large footprints on small lots 10Tuesday, 12 March, 13
  12. 12. The Economics of Big Houses • Mass produced, limited customization • Corners cost money • Do not require domain knowledge by the builder • Nothing in their work or work products reflects the homeowner except the name on the cheque 11Tuesday, 12 March, 13
  13. 13. What problem do big houses solve? 12Tuesday, 12 March, 13
  14. 14. 13Tuesday, 12 March, 13
  15. 15. 13Tuesday, 12 March, 13
  16. 16. How do you sell a house to someone who doesnt know what they need? • Most home buyers dont understand their own needs now or as they are likely to evolve • Most home buyers dont understand how homes function 14Tuesday, 12 March, 13
  17. 17. most home buyers are uncertain 15Tuesday, 12 March, 13
  18. 18. uncertainty creates fear 16Tuesday, 12 March, 13
  19. 19. fearful people cling to the simple and obvious 17Tuesday, 12 March, 13
  20. 20. Selling homes by volume is about as simple and as obvious as you can get. 18Tuesday, 12 March, 13
  21. 21. The result? Under- or poorly- designed homes • We are impressed by high ceilings, but feel safer in smaller spaces. • Big homes have rarely used rooms. • The default is for big homes to skip functionality we actually use, like built-in storage or pocket doors.* 19Tuesday, 12 March, 13
  22. 22. The problem with Big Homes: They dont serve their owners needs But they persist, because thats what sells to people who have little understanding of their own needs, and little experience with how homes function. 20Tuesday, 12 March, 13
  23. 23. and now to the main event... 21Tuesday, 12 March, 13
  24. 24. THE NOT-SO-BIG SOFTWARE DESIGN 22Tuesday, 12 March, 13
  25. 25. THE NOT-SO-BIG SOFTWARE DESIGN Part I: The Problem 23Tuesday, 12 March, 13
  26. 26. What is "Not-So-Big?" • SMB and departmental applications • Emphasis on what is unique to each application • Form follows domain functionality • Says "no" to popular conception of value: The default arrangement of components 24Tuesday, 12 March, 13
  27. 27. No standard arrangement? Why? 25Tuesday, 12 March, 13
  28. 28. The Big Framework • Designed for mass production and mass consumption • Boxes for components 26Tuesday, 12 March, 13
  29. 29. The Economics of Big Frameworks • Limited menu of choices • Easy on-ramp for new developers • Domain-free design creates the illusion of portable skills • Very little in their work or work products reflects the customer except the name on the cheque 27Tuesday, 12 March, 13
  30. 30. What problem do big frameworks solve? 28Tuesday, 12 March, 13
  31. 31. How do you get started quickly with a new project? • The domain is not fully understood at the beginning of a project, but a domain-agnostic framework doesnt "care.". • Reusing the same framework over and over again allows reuse of skills and experience... with the framework. 29Tuesday, 12 March, 13
  32. 32. Frameworks are chosen early • Minimum knowledge • Maximum uncertainty 30Tuesday, 12 March, 13
  33. 33. developers are uncertain 31Tuesday, 12 March, 13
  34. 34. uncertainty creates fear 32Tuesday, 12 March, 13
  35. 35. fearful people cling to the simple and obvious 33Tuesday, 12 March, 13
  36. 36. Organizing software around "the things you know youll need" is about as simple and as obvious as you can get. 34Tuesday, 12 March, 13
  37. 37. Is The Result Poorly Designed Software? 35Tuesday, 12 March, 13
  38. 38. Is The Result Poorly Designed Software? ...exempla gratia... 35Tuesday, 12 March, 13
  39. 39. A 1962 VW Camper Van 36Tuesday, 12 March, 13
  40. 40. A 1962 VW Camper Van 36Tuesday, 12 March, 13
  41. 41. A 1962 VW Camper Van 36Tuesday, 12 March, 13
  42. 42. Is the result poorly-designed software? • If I look at the lists of models, controllers, views, assets, configuration files, migrations, and so forth, can I tell what it is supposed to do? • Great, there are more than a thousand tests. Why are the tests that describe what it it supposed to do completely decoupled from the code that does it? • We build once but change and fix for years. Are we optimizing for the thing thats easy to sell? 37Tuesday, 12 March, 13
  43. 43. The problem with Big Homes: They dont serve their owners needs But they persist, because thats what sells to people who have little understanding of their own needs, and little experience with how homes function. 38Tuesday, 12 March, 13
  44. 44. The problem with Big Homes: Big Fram needs They dont serve their owners or ew ks But they persist, because thats what sells. Our job is to discard the habits that served us well when we were learning, and develop new habits that put us first and the framework second. 38Tuesday, 12 March, 13
  45. 45. A Not-So-Big Home 39Tuesday, 12 March, 13
  46. 46. THE NOT-SO-BIG SOFTWARE DESIGN Part II: Good Habits 40Tuesday, 12 March, 13
  47. 47. Problem: By default, code gives all use cases equal weight • If you only entertain formally twice a year, why would your formal dining room take up more space and more mindshare than the eat-in nook in the kitchen? 41Tuesday, 12 March, 13
  48. 48. Accommodating how you actually live, not how you pretend to live. 42Tuesday, 12 March, 13
  49. 49. Less frequent use cases are hidden away 43Tuesday, 12 March, 13
  50. 50. Hide the necessary but infrequent or unimportant • Make heavy use of AOP-ish filters, monkey-patching, method decorators, modules, and other tools so that classes and methods are light in the editor even if theyre heavy in the runtime. • Push grunt-work into gems. • Consider using "The Williams Style" for implementation concerns 44Tuesday, 12 March, 13
  51. 51. Problem: All the bathrooms on one floor, all the bedrooms on another 45Tuesday, 12 March, 13
  52. 52. Problem: All the bathrooms on one floor, all the bedrooms on another 45Tuesday, 12 March, 13
  53. 53. Organize code by use, not by type • Frameworks like Rails have a default organization, but they can be configured to put things wherever you want. • Make heavy use of modules to namespace code and also to put like code with like. • Cultivate a "refined taste." 46Tuesday, 12 March, 13
  54. 54. Problem: Documentation "Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits."--Alan J. Perlis 47Tuesday, 12 March, 13
  55. 55. Problem: Documentation This space about documenting implementation code left intentionally blank. 48Tuesday, 12 March, 13
  56. 56. Use maximally literate test code • Embed specs, test cases, and other vegetative artefacts within marked up documentation using Literate CoffeeScript, Docco, or other similar tools. • Building your docs should be part of your deploy. • Your literate test code must be read and re-read to be worthwhile. 49Tuesday, 12 March, 13
  57. 57. 50Tuesday, 12 March, 13
  58. 58. Three Not-So-Big Habits • Hide or de-emphasize the infrequent or unimportant • Organize code by use, not type • Write maximally literate test code 51Tuesday, 12 March, 13
  59. 59. The Message • Our needs at the start of our experience with a framework or project should not dominate our choices • Good design emphasizes what is frequent and important in houses, UX, and software design • You are an important user. Design with you in mind. 52Tuesday, 12 March, 13
  60. 60. Dziękuję bardzo! "It is easier to write an incorrect program than understand a correct one."--Alan J. Perlis 53Tuesday, 12 March, 13
  61. 61. reg braithwaite http://braythwayt.com 54Tuesday, 12 March, 13

×