[Getting Real](https://basecamp.com/gettingreal/getting-real.pdf) is a book by Jason Fried, David Heinemeier Hansson, and Matthew Linderman of 37signals. It's about skipping all the stuff that represents real ## Starting > When there's **too many people involved**, nothing gets done. > Many months are spent on planning features and arguing details with the goal > of everyone reaching an agreement on what is the "right" thing for the > customer. > Months of writing specs are not necessary — specs should have the foundations > nailed and details figured out and refined during the development phase. > 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 foregoes functional specs and other transitory documentation in > favor of building real screens. > Getting Real gets rid of... Timelines that take months or even years > Pie-in-the-sky functional specs Scalability debates Interminable staff > meetings The "need" to hire dozens of employees Meaningless version numbers > Pristine roadmaps that predict the perfect future Endless preference options > Outsourced support Unrealistic user testing Useless paperwork Top-down > hierarchy You don't need tons of money or a huge team or a lengthy development > cycle to build great software. Those things are the ingredients for slow, > murky, changeless applications. Getting real takes the opposite approach. ## Change > The **ability to change is key**. Having everything fixed makes it tough to > change. > If your competition is faster, you must be cheaper. If they sell the story of > health, you must sell the story of convenience. > A lot of small companies make the mistake of trying to act big. > Mass is increased by... Long term contracts Excess staff Permanent decisions > Meetings about other meetings Thick process Inventory (physical or mental) > Hardware, software, technology lock-ins Proprietary data formats The past > ruling the future Long-term roadmaps Office politics > Change is your best friend. > If change **gets too expensive, you're dead**. > When it comes to web technology, change must be easy and cheap. > Ignore Details Early On Work from large to small > Don't worry about the size of your headline font in week one. You don't need > to nail that perfect shade of green in week two. You don't need to move that > "submit" button three pixels to the right in week three. Just get the stuff on > the page for now. Then use it. Make sure it works. ## New features > Believe it or not, the bigger problem isn't scaling, it's **getting to the point** > where you **have to scale**. Without the first problem you won't have the second. > Organizations need guideposts. They need an outline; employees need to know > each day when they wake up why they're going to work. > Take whatever you think your product should be and cut it in half. Pare > features down until you're left with only the most essential ones. > For every new feature you need to... > > 1. **Say no.** > 2. Force the feature to prove its value. > 3. If "no" again, end here. If "yes," continue... > 4. Sketch the screen(s)/ui. > 5. Design the screen(s)/ui. > 6. Code it. 7-15. Test, tweak, test, tweak, test, tweak, test, tweak... > 7. Check to see if help text needs to be modified. > 8. Update the product tour (if necessary). > 9. Update the marketing copy (if necessary). > 10. Update the terms of service (if necessary). > 11. Check to see if any promises were broken. > 12. Check to see if pricing structure is affected. > 13. Launch. > 14. Hold breath. > Ask people what they don't want > Innovation comes from saying no to 1,000 things to make sure we don't get on > the wrong track or try to do too much. > Most of the time you spend is wasted on things that just don't matter. If you > can cut out the work and thinking that just don't matter, you'll achieve > productivity you've never imagined. > It is simply too easy, and sometimes fun, to waste valuable time inventing > features that turn out to be unnecessary or unimplementable. ## Environment and hires > Guess which part of the day we get the most work done? The alone part. It's > not that surprising really. Many people prefer to work either early in the > morning or late at night — **times when they're not being bothered**. > The **alone zone** is where **real progress** is made. > Getting in the zone takes time. And that's why interruption is your enemy. > It's like rem sleep — you don't just go to rem sleep, you go to sleep first > and you make your way to rem. Any interruptions force you to start over. rem > is where the real sleep magic happens. The alone time zone is where the real > development magic happens. > They usually convey an abysmally small amount of information per minute > Judge potential tech hires on open source contributions > A single good programmer working on a single task has no coordination or > communication overhead. Five programmers working on the same task must > coordinate and communicate. That takes a lot of time... The real trouble with > using a lot of mediocre programmers instead of a couple of good ones is that > no matter how long they work, they never produce something as good as what the > great programmers can produce. > **Enthusiasm**. It's one attribute you just **can't fake**. > Someone you can trust to get things done **when left alone**. > At Creative Good, we call it "intelligent inconsistency": making sure that > each page in the process gives users exactly what they need at that point in > the process. ## Design > Copywriting is interface design. > Whatever the page absolutely can't live without is the epicenter. > Only when that unit is complete would you begin to think about the second most > critical element on the page. Then after the second most critical element, > you'd move on to the third, and so on. That's epicenter design. > Epicenter design flips that process and allows you to focus on what really > matters on day one. Essentials first, extras second. > "Defensive Design for the Web" 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. > To avoid crappy-admin-screen syndrome, don't build separate screens to deal > with admin functions. Instead, build these functions (i.e. edit, add, delete) > into the regular application interface. > Much like a weblog, it's up to them to populate it — the overall look and feel > doesn't take shape until people enter their data: posts, links, comments, > hours, sidebar info, or whatever. > Use it as an opportunity to insert quick tutorials and help blurbs. Give a > sample screenshot of the page populated with data so people know what to > expect (and why they should stick around). Explain how to get started, what > the screen will eventually look like, etc. Answer key questions that > first-time viewers will ask: What is this page? What do I do now? How will > this screen look once it's full? Set expectations and help reduce frustration, > intimidation, and overall confusion. > You Never Get A Second Chance... > Is a new feature requiring weeks of time and thousands of lines of code? > That's your code telling you there's probably a better way. > **If programmers got paid to remove code from software instead of writing new > code, software would be a whole lot better.** > Keep your code as simple as possible each time you increase the amount of code, > your software grows exponentially more complicated. Each minor addition, each > change, each interdependency, and each preference has a cascading effect. > The way you fight this complexity is with less software. Less software means > less features, less code, less waste. > Less software is easier to manage. Less software reduces your codebase and > that means less maintenance busywork (and a happier staff). Less software > lowers your cost of change so you can adapt quickly. You can change your mind > without having to change boatloads of code. Less software results in fewer > bugs. Less software means less support. > **There is No CODE That is More Flexible Than NO Code!** > Don't try to lock-in your customers. Let them get their information when they > want it and how they want it. ## Motivating > Optimize for Happiness Choose tools that keep your team excited and motivated > Would you truly be happy working in this environment eight hours a day? > Happiness has a cascading effect. Happy programmers do the right thing. They > write simple, readable code. They take clean, expressive, readable, elegant > approaches. They have fun. > Don't Do Dead Documents Eliminate unnecessary paperwork > Documents that live separately from your application are worthless. > Documents that live separately from your application are worthless. They don't > get you anywhere. > Don't waste your time typing up that long visionary tome; no one's going to > read it. > I've even worked with developers who've spent hours writing long, descriptive > emails or coding standards documents that also went unread. ## Documenting > **Functional specs are fantasies!** > There's Nothing Functional about a Functional Spec Don't write a functional > specifications document > Functional specs lead to feature overload > Write a one page story about what the app needs to do. Use plain language and > make it quick. If it takes more than a page to explain it, then it's too > complex. > A "spec" is close to useless. I have never seen a spec that was both big > enough to be useful and accurate. And I have seen lots of total crap work that > was based on specs. It's the single worst way to write software, because it by > definition means that the software was written to match theory, not reality. > Use Real Words Insert actual text instead of lorem ipsum > **Easy On, Easy Off Make signup and cancellation a painless process** > There should always be a free option so customers can demo the app without > entering credit card information. > Keep the signup form as short as possible. Don't ask for stuff you don't need > and don't throw a long daunting form at people. > Don't hold users against their will. If they want to leave, let them pick up > with all of the content they created while they were on your site and > leave...for free... > Ask them if they want to be included on your special advance list so they'll > be among the first to know about future releases, updates, etc. Collect > positive praise and create a "buzz" page at your site. > During business hours, we answer 90% of all email support requests within 90 > minutes — and often within a half-hour. And people love it. > You don't need a manual to use Yahoo or Google or Amazon. So why can't you > build a **product that doesn't require a manual**? Strive to build a tool that > requires zero training. > Just because you discover a bug in your product, doesn't mean it's time to > panic. All software has bugs — it's just a fact of life. > These days it feels like everything is in beta stage forever. That's a cop > out. An interminable beta stage tells customers you're not really committed to > rolling out a finished product. It says, "Use this, but if it's not perfect, > it's not our fault." ## Betas > **Private betas are fine, public betas are bullshit.** > Don't wait for your **product to reach perfection**. > Is it just me, or are we all in beta, all the time? > Sometimes it's ok to just be a pencil. You don't need to be a swiss-army > knife. > With web-based software based on the subscription model, people pay a monthly > fee to use the service. You don't need to keep upselling them by adding more > and more and more, you just need to provide an ongoing valuable service.