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!

There's Nothing Functional about a Functional Spec

• Don't write a functional specification document: these blueprints rarely match the finished project
• Why?
  • Functional specs are fantasies: they don't reflect reality
    • An app isn't real until designers are designing it, builders are building it, users are using it
  • Functional specs are about appeasement
    • They are typically about making people happy rather than making tough choices
  • Functional specs only lead to an illusion of agreement
    • Often people have different interpretations of the same text and so don't realize that they haven't yet reached a “shared understanding”.

Don't Do Dead Documents

• Eliminate unnecessary paperwork
  • Avoiding functional specs is a good start, but try avoiding all excess paperwork
• If a document is not going to evolve into something real, don't produce it
• Documents that live separately from your application are worthless

Striking parallels with Agile methods here; but, how would such a philosophy work in larger more formal settings?

Three State Solution: Design for regular, blank, and error states

• Design for three states of your application
  • Regular: application is “flush” with data; normal use
  • Blank: The screen people see when they first use your application; very little data or none at all
  • Error: What people see when something goes wrong
• Related Articles
  • The Blank Slate: Set expectations with a thoughtful first-run experience
  • Get Defensive: Design for when things go wrong. “Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they’re unlikely to forget it.”

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

Meetings are Toxic

• The team should work to avoid meetings as much as possible
• Concept too complex? Simplify it, so it can be discussed via e-mail or IM
• “Every minute you avoid spending in a meeting is a minute you can get real work done instead.”
• Why are meetings toxic to productivity?
  • Break work day into incoherent pieces, hinder ability to work “in the flow”
  • Usually about abstract things (concepts), not real things (code, interface design)
  • Convey abysmally small amount of information per minute
  • Can be controlled by people who deliberately waste people's time
  • Easily drift off subject
  • Vague agendas
  • Require thorough preparation that people rarely invest

Ride the Blog Wave

• Blogging is (a lot) cheaper than advertising
• Create a blog that not only advertises your products but presents advice, hints, tips, etc.
• “Ta-da Lists is another great example of the power of blog-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it had been mentioned on over 200 blogs and over 12,000 people had signed up for their own Ta-da account. Word about Backpack spread even faster. Within 24 hours of launch, more than than 10,000 signed up.”

Lots More to Cover

• Here are a few chapter titles that contain important ideas
  • Fix Time and Budget, Flex Scope
  • Avoid Preferences
  • Feel the Pain
  • Zero Training
  • All Bugs are not Created Equal

Coming Up Next

• Lecture 30: Project Demos in room ECCS 127 (not in the CAETE studio)
• Reminders:
  • No Final (!)
  • I will take teams on Thursday on a first come, first served basis. I am also happy to meet with teams during my office hours on Thursday from 1 PM to 1:45 PM. Office hours will be held in ECCS 127, not ECOT 822.