the not so-big software design

Good morning wroc_love.rb!

1

Tuesday, 12 March, 13

The reputation of a speaker varies with the square of the distance travelled to speak.

2


3

the preamble...


THE NOT-SO-BIG HOUSE4


Sarah Susanka

• Residential Architect

• Author, "The Not-So-Big-House" and "The Not-So-Big Life" amongst others

5


6

THE NOT-SO-BIG HOUSEPart I: The Problem


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


2,400 sq. ft. for the price of 4,000!?

Why?

8


9


The Big House

• 4,000 sq. ft. or more.

• Vaulted and double-height spaces

• Boxes for people

• Large footprints on small lots

10


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


12

What problem do big houses solve?


13


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


15

most home buyers are uncertain


16

uncertainty creates fear


17

fearful people cling to the simple and obvious


18

Selling homes by volume is about as simple and as obvious as you can get.


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


The problem with Big Homes:They don't serve their owners' needs

20

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.


21

and now to the main event...


THE NOT-SO-BIG SOFTWARE DESIGN

22


23

THE NOT-SO-BIGSOFTWARE DESIGN

Part I: The Problem


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


No standard arrangement?

Why?

25


The Big Framework

• Designed for mass production and mass consumption

• Boxes for components

26


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


28

What problem do big frameworks solve?


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


Frameworks are chosen early

• Minimum knowledge

• Maximum uncertainty

30


31

developers are uncertain


32

uncertainty creates fear


33

fearful people cling to the simple and obvious


34

Organizing software around"the things you know you'll need"is about as simple and as obvious

as you can get.


Is The Result Poorly Designed Software?

35


Is The Result Poorly Designed Software?

35

...exempla gratia...


A 1962 VW Camper Van

36


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



38

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

Big Frameworks

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.


A Not-So-Big Home

39


40

THE NOT-SO-BIGSOFTWARE DESIGN

Part II: Good Habits


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


Accommodating how you actually live, not how you pretend to live.

42


Less frequent use cases are hidden away

43


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


Problem: All the bathrooms on one floor, all the bedrooms on another

45


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


Problem: Documentation

47

"Documentation is like term insurance: It satisfies because almost no one who subscribes

to it depends on its benefits."--Alan J. Perlis


Problem: Documentation

48

This space about documenting implementation code left intentionally blank.


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


50


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


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


Dziękuję bardzo!

53

"It is easier to write an incorrect program than understand a correct one."--Alan J. Perlis


reg braithwaitehttp://braythwayt.com

54


the not so-big software design

Documents