The document is a transcript of a presentation on designing software applications based on principles of "Not-So-Big" home design. It discusses how large, generic frameworks and default component arrangements may result in poorly designed software that doesn't serve the actual needs of its users. It promotes organizing code by usage rather than type, hiding infrequent elements, and using literate test documentation to improve design. The overall message is that software design should emphasize frequent, important user needs rather than early-stage assumptions or framework conventions.

1. Good morning wroc_love.rb!
1
Tuesday, 12 March, 13

2. The reputation of a speaker varies with the
square of the distance travelled to speak.
2
Tuesday, 12 March, 13

3. The reputation of a speaker varies with the
square of the distance travelled to speak.
2
Tuesday, 12 March, 13

4. the preamble...
3
Tuesday, 12 March, 13

5. THE NOT-SO-BIG HOUSE
4
Tuesday, 12 March, 13

6. Sarah Susanka
• Residential Architect
• Author, "The Not-So-Big-
House" and "The Not-So-
Big Life" amongst others
5
Tuesday, 12 March, 13

7. THE NOT-SO-BIG HOUSE
Part I: The Problem
6
Tuesday, 12 March, 13

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
7
Tuesday, 12 March, 13

9. 2,400 sq. ft. for the price of 4,000!?
Why?
8
Tuesday, 12 March, 13

10. 9
Tuesday, 12 March, 13

11. The Big House
• 4,000 sq. ft. or more.
• Vaulted and double-height spaces
• Boxes for people
• Large footprints on small lots
10
Tuesday, 12 March, 13

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
11
Tuesday, 12 March, 13

13. What problem do big houses solve?
12
Tuesday, 12 March, 13

14. 13
Tuesday, 12 March, 13

15. 13
Tuesday, 12 March, 13

16. How do you sell a house to someone
who doesn't know what they need?
• Most home buyers don't understand their own needs now
or as they are likely to evolve
• Most home buyers don't understand how homes function
14
Tuesday, 12 March, 13

17. most home buyers are uncertain
15
Tuesday, 12 March, 13

18. uncertainty creates fear
16
Tuesday, 12 March, 13

19. fearful people cling to the simple and obvious
17
Tuesday, 12 March, 13

20. Selling homes by volume is
about as simple and as
obvious as you can get.
18
Tuesday, 12 March, 13

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.*
19
Tuesday, 12 March, 13

22. The problem with Big Homes:
They don't serve their owners' needs
But they persist, because that's what sells
to people who have little understanding of
their own needs, and little experience with
how homes function.
20
Tuesday, 12 March, 13

23. and now to the main event...
21
Tuesday, 12 March, 13

24. THE NOT-SO-BIG
SOFTWARE DESIGN
22
Tuesday, 12 March, 13

25. THE NOT-SO-BIG
SOFTWARE DESIGN
Part I: The Problem
23
Tuesday, 12 March, 13

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
24
Tuesday, 12 March, 13

27. No standard arrangement?
Why?
25
Tuesday, 12 March, 13

28. The Big Framework
• Designed for mass production and mass consumption
• Boxes for components
26
Tuesday, 12 March, 13

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
27
Tuesday, 12 March, 13

30. What problem do big frameworks solve?
28
Tuesday, 12 March, 13

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 doesn't "care.".
• Reusing the same framework over and over again allows
reuse of skills and experience... with the framework.
29
Tuesday, 12 March, 13

32. Frameworks are chosen early
• Minimum knowledge
• Maximum uncertainty
30
Tuesday, 12 March, 13

33. developers are uncertain
31
Tuesday, 12 March, 13

34. uncertainty creates fear
32
Tuesday, 12 March, 13

35. fearful people cling to the simple and obvious
33
Tuesday, 12 March, 13

36. Organizing software around
"the things you know you'll need"
is about as simple and as obvious
as you can get.
34
Tuesday, 12 March, 13

37. Is The Result Poorly Designed
Software?
35
Tuesday, 12 March, 13

38. Is The Result Poorly Designed
Software?
...exempla gratia...
35
Tuesday, 12 March, 13

39. A 1962 VW Camper Van
36
Tuesday, 12 March, 13

40. A 1962 VW Camper Van
36
Tuesday, 12 March, 13

41. A 1962 VW Camper Van
36
Tuesday, 12 March, 13

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 that's easy to sell?
37
Tuesday, 12 March, 13

43. The problem with Big Homes:
They don't serve their owners' needs
But they persist, because that's what sells
to people who have little understanding of
their own needs, and little experience with
how homes function.
38
Tuesday, 12 March, 13

44. The problem with Big Homes:
Big
Fram needs
They don't serve their owners' or
ew
ks
But they persist, because that's 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.
38
Tuesday, 12 March, 13

45. A Not-So-Big Home
39
Tuesday, 12 March, 13

46. THE NOT-SO-BIG
SOFTWARE DESIGN
Part II: Good Habits
40
Tuesday, 12 March, 13

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?
41
Tuesday, 12 March, 13

48. Accommodating how you actually
live, not how you pretend to live.
42
Tuesday, 12 March, 13

49. Less frequent use cases are hidden away
43
Tuesday, 12 March, 13

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 they're
heavy in the runtime.
• Push grunt-work into gems.
• Consider using "The Williams Style" for implementation
concerns
44
Tuesday, 12 March, 13

51. Problem: All the bathrooms on one
floor, all the bedrooms on another
45
Tuesday, 12 March, 13

52. Problem: All the bathrooms on one
floor, all the bedrooms on another
45
Tuesday, 12 March, 13

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."
46
Tuesday, 12 March, 13

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
47
Tuesday, 12 March, 13

55. Problem: Documentation
This space about documenting implementation
code left intentionally blank.
48
Tuesday, 12 March, 13

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.
49
Tuesday, 12 March, 13

57. 50
Tuesday, 12 March, 13

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
51
Tuesday, 12 March, 13

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.
52
Tuesday, 12 March, 13

60. Dziękuję bardzo!
"It is easier to write an incorrect program than
understand a correct one."--Alan J. Perlis
53
Tuesday, 12 March, 13

61. reg braithwaite
http://braythwayt.com
54
Tuesday, 12 March, 13