Book Review: Getting Real

This is a review of Getting real, a book by the team at 37Signals about building software faster. It’s (thankfully 😇) relatively short with ~ 14 chapters and ~ 171 pages.

1 starting line

defensive companies can’t think ahead; they can only think behind. They don’t lead, they follow.

build for yourself

fund yourself

  • constraints force creativity
  • fix time + budget, flex scope
  • pull back scope
  • prioritization, reality, flexibility

have an enemy

it shouldn’t be a chore

2 stay lean

less mass

  • mass is ↑ by thick process, lock-ins, closed data formats, office politics etc.
  • mass is ↓ by JIT thinking, less software/less code, less features, simplicity, pared-down interface, OSS, open data formats, open culture

startups are cool because can change their minds 🧠

lower your cost of change

  • emergence
  • emergent properties happen as a dynamic result of a system

the 3 musketeers

  • use a team of 3 for v1

embrace constraints

be yourself

3 priorities

what’s the big idea

ignore details early on

it’s a problem when it’s a problem

hire the right customers

scale later

4 feature selection

  • build half a product
  • it just doesn’t matter
  • start with no
  • hidden costs
  • can you handle it
  • forget feature requests
    • read them then throw away
  • hold the mayo

5 process

race to running software

  • get something up and running quickly

rinse + repeat

  • work in iterations
  • don’t expect to get it perfect the first time; let it morph + evolve 🦎

from idea to implementation

  • brainstorm 🧠⛈️ → sketches → HTML → coding

avoid preferences

  • preferences are evil as they create more software
  • more options require more code
  • make the call

done!

  • decisions are temporary so make the call and move on
  • ideas are just multipliers (max double digits) times execution (worth millions)
  • test in the wild

shrink your time

  • are you facing a Big problem?
  • break it down into smaller pieces

6 the organization

unity

  • don’t split into silos

alone time

  • get 💩 done

meetings are toxic

  • set a timer
  • invite as few people as possible
  • have a clear agenda

seek and celebrate small victories

  • the most important thing in SD is motivation
  • 4-hour quick wins (builds morale, ^ motivation, reaffirms team is → right direction)

7 staffing

hire less and hire later

Brooks’ law

Adding people to a late software project makes it later (Fred Brooks)

kick the tires 🚗

  • take potential new team members on a test drive

actions, not words

  • judge hires on OSS contributions
  • quality of work
  • cultural perspective
  • level of passion
  • completion percentage
  • social match

If you want something done, ask the busiest person you know

get well rounded individuals

you can’t fake enthusiasm

  • happy + average > frustrated + great

wordsmiths

  • hire good writers (when deciding over a designer, programmer, marketer, salesperson, etc.)
  • good writers know how to communicate

8 interface design

interface first

  • design interface before you start programming
  • interface is your product

epicenter design

  • start from core + build outward

3 state solution

  • regular 💚 blank 🤍 error 🔴

first impressions are important

get defensive

  • when things go wrong

context over consistency

copywrighting is interface design

9 code

less software

  • each time you increase code, your software grows exponentially more complicated
  • keep code as simple as possible (KISS)
  • big ball of mud 🟤
  • solving 80% of the problem for 20% of the effort is a major win
  • search for detours around writing more software
  • complexity doesn’t scale linearly with size (ganssle group)

optimize for happiness

code speaks

manage debt

open doors

  • don’t seal in data, let it run wild
  • RSS feeds, APIs

10 words

there’s nothing functional about a functional spec

  • don’t write them

A “spec” is close to useless. I have never seen a spec that was both big enough to be useful and accurate. – Linus Torvalds (from Linux: Linus On Specifications)

don’t do dead docs

tell me a quick story 🧙‍♂️

use real words

  • use real words, not lorem ipsum

personify your product

11 pricing and signup

free samples

easy on, easy off

  • easy signup, easy cancellation

12 promotion

hollywood launch ⭐

  • teaser → preview → launch

ride the blog wave

  • can be more effective than advertising, and it’s cheaper

track your logs

  • leave comments on blogs
  • thank people for posting links
  • create ‘buzz’ page on site

inline upsell

name hook

  • short, catchy, memorable and run with it

13 support

feel the pain

  • DIY

answer quick

tough love

  • decided not to support IE5 (7% of market)
  • customer is right | customer isn’t always right

in fine forum

  • people help one another

publicize your screwups

14 post launch

1 month tuneup

  • issue major update 30 d after launch

keep the posts coming

  • blog shows app is alive and makes your company seem more human ⛹️‍♀️

all bugs are not created equal

  • some bugs are more important

beware the bloat monster 👻

go with the flow

  • be open to change

15 conclusion

Conclusion

This is the 3rd book I’ve read from team 37signals remote, rework. I really like their philosophy, which is to keep it simple and move fast.

Amazon has a culture called Day 1 which includes tactics like having a 2 pizza team, and customer obsession.

Overall I’d give it a ★★★★☆.

Additional reading

  • the pragmatic programmer – hunt
  • seth godin

Leave a Reply

Your email address will not be published. Required fields are marked *