Getting Real

• A way to do software development for Web applications written by the employees of 37signals
  • Note: Book is available here
  • Available in three formats: HTML (free), PDF ($19), and hard copy ($29)
• Data point: They claim to use this method for building their own software. As they put it: 37signals used the unconventional Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no funding, no debt, and only 7 people.
• Getting Real's Tag Line: The smarter, faster, easier way to build a successful web application
• Approach has elements of Agile life cycles
• Beware the Tone of the Book

Structure of Book

• 86 essays divided into 14 chapters (ignoring the Intro and Conclusions)
  
  

  2. The Starting Line	9. Interface Design
  3. Stay Lean	10. Code
  4. Priorities	11. Words
  5. Feature Selection	12. Pricing and Signup
  6. Process	13. Promotion
  7. The Organization	14. Promotion
  8. Staffing	15. Post-Launch

• Each essay is short and attempts to make a single point, often with supporting quotes from other Web 2.0 developers
• Important concepts are repeated in multiple essays; the repetition attempts to reinforce the main points

Getting Real: More Philosophy Than Structured Process

• The overall book has the feel of another Agile Manifesto
• There are important points made, significant issues raised BUT…
• details on how to operationalize the philosophy into a repeatable process are left to the reader

Example

• As an example, here is 37signals answer to the question “What is Getting Real?”
  • Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
  • Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).
  • Getting Real is staying small and being agile.
  • Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
  • Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
  • Getting Real delivers just what customers need and eliminates anything they don't.

We'll cover the following essays

Build Less

• Main Point: Do less than your competition
  • Keep your focus simple and then excel at doing what you do
• Broad concept that applies to
  • Software: less software, less features, less preferences
  • Organization: less meetings, less people, less resources, less external commitments
  • Process: less artifacts, less coordination, less infrastructure

What's Your Problem?

• Main Point: Build software for yourself
  • Sometimes phrased: Write software that scratches an itch
• If you write software that solves a problem you're encountering, then YOU are the CLIENT
  • And if you have this problem, its likely that others do too
• Basecamp was created because 37signals
  1. needed its functionality
  2. could not find existing software that met their needs
Claim: When you solve your own problem, you create software that you're passionate about
• with passion, you will use your own software and care about it
• And such software is likely to incite passion in others (i.e. your potential customers!)

Fund Yourself

• Avoid outside constraints, attempt to fund your own efforts
• Startup costs for Web development are relatively low
  • Hardware is cheap
  • Internet access is cheap
  • Lots of open source software to leverage
• Using your own funds, places constraints on your work
  • 37signals argues that these constraints are a GOOD thing
    • You will be forced to do more with less
    • The constraints will require creativity and innovation
    • The constraints will drive you to release sooner and thus give you access to feedback sooner
    • As they say A month or two out of the gates you should have a pretty good idea of whether you’re onto something or not. If you are, you’ll be self-sustainable shortly and won’t need external cash. If your idea’s a lemon, it’s time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved.

Have an Enemy

• The best way to guide your design is to know what you want to avoid
• With Basecamp, 37signals defined their “enemy” as Microsoft Project
• They knew they wanted project management software that was nowhere near Project's spot in the design space
  • As a result, Basecamp has no charts, no graphs, no reports, no statistics
  • Instead it focuses on supporting communication and fostering group ownership of a project
• However: don't get obsessed with analyzing your competition. Set the enemy at a high level and then focus on the design of your own system

Lower Your Cost of Change

• Stay flexible by reducing obstacles to change. Change is your best friend!
• Shared philosophy with Agile Design
• In order to do this, they recommend “staying lean”
  • Keep your company small, smaller companies can change more quickly than larger companies
  • Just in time thinking: Don't solve potential problems, focus on actual problems
  • Keep your software and designs simple: Less features, less code, spare interfaces, etc.
  • Employees that play multiple roles, distributed expertise, open culture with no penalty for admitting mistakes

The Three Musketeers

• Use a team of three developers to build version 1.0 of your product
  • Small teams keep communication paths to a minimum
  • Communication paths increase multiplicatively: n(n-1)/2
• Echos of Fred Brooks' concept of conceptual integrity
• Forces you to find the right people for your team: look for the best
• Forces you to keep your first version properly scoped

What's the Big Idea?

• Similar to Agile Design's “Metaphor”
• Explicitly define the one-point vision for your app
• Here’s the vision for each of 37signals' products:
  • Basecamp: Project management is communication
  • Backpack: Bring life’s loose ends together
  • Campfire: Group chat over IM sucks
  • Ta-da List: Competing with a post-it note
  • Writeboard: Word is overkill

Hire the Right Customers

• Find the core market for your application and focus solely on them
• If you try to please everyone, you won't please anyone

Scale Later

• Q. Will my app scale when millions of people start using it?
• A. You don't have millions of users yet!
• 37signals ran Basecamp on a single server for a year after launch
  • Kept costs low and operations simple
  • Didn't switch to something more complex until their user base grew to the point when it was required
  • They then had actual usage data to drive the process of what configuration they needed to move to

Half, Not Half-Assed

• Take your idea for your product and cut it in half
• Force your design to the bare minimum you need to address your problem domain
• Enables the ability to create an excellent product, as opposed to a mediocre product with incomplete features

Human Solutions

• Build software for general concepts and encourage people to create their own solutions
• Users will often take generic features and adapt/use them in ways you did not anticipate
• Ta-da List is a 37signals product that does to-do lists
  • It handles creating lists, reordering list items, checking off completed items
  • It does not handle due dates, categories, assigning tasks to users
  • But user's didn't care: they entered textual annotations to their list items to handle those features when they needed them
• This approach allows you to avoid speculating on the features your users need and only implement those they are clamoring for
• Indeed one chapter is called “Forget Feature Requests”: they recommend throwing feature requests out... if a feature is truly important, all your customers will be asking for it and you won't be able to forget it!

Race to Running Software / Rinse and Repeat

• Get something real up and running quickly
• Similar to Agile Design's “Release Early, Release Often”
• Work in iterations: Don't aim for perfection on the first try; Get close and then slowly move closer

From Idea to Implementation

• First chapter that provides process details
• 37signals process involves
  • Brainstorm: Big questions, vision, not nitty gritty details
  • Paper Sketches: Get ideas out of your head and onto paper, iterate
  • Create HTML screens: Mock up final sketches in HTML and CSS
  • Code it: When the mock-up looks good, write the code that makes it functional
• Iterate.... a lot!

Alone Time

• People need uninterrupted time to get things done
• This is directly opposed to Agile Design's philosophy!
• Recommendation: Make at least half the work day alone time; no interruptions or meetings allowed

Lots More to Cover

• Here are a few chapter titles that contain important ideas
  • Meetings are Toxic
  • Three State Solution: Design for regular, blank, and error states
  • There's Nothing Functional about a Functional Spec
  • Don't Do Dead Documents
  • Ride the Blog Wave: Blogging is cheaper than advertising

Discussion

• Interesting chapters and/or issues I missed?
• Relationship to Traditional and Agile Life Cycles
• Will it work for non Web applications?

Coming Up Next

• Lecture 30: Model-Based Design
• Reminders:
  • No Final (!)
  • Make arrangements to meet with me next week to turn in the final assignment of the class project