Getting Real: The Smarter, Faster, Easier Way to Build a Web Application by 37 Signals
My rating: 4 of 5 stars
The book is written for those who create web applications, but as a web designer who creates WordPress websites, I found plenty of relevant advice about planning, project management, client relations, hiring, and productivity. The 37 Signals authors make many similar points in Rework.
You can download the book for free.
Introduction
"Months of planning are not necessary. Months of writing specs are not necessary – specs should have the foundations nailed and details figured out and refined during the development phase. Don’t try to close all open issues and nail every single detail before development starts."
Fix Time and Budget, Flex Scope
"Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope."
It’s a Problem When It’s a Problem
- "People often spend too much time up front trying to solve problems they don’t even have yet."
- "Don’t sweat stuff until you actually must. Don’t overbuild."
- "Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care."
It Just Doesn’t Matter
- "The best designers and the best programmers aren’t the ones with the best skills… they are the ones that can determine what just doesn’t matter. That’s where the real gains are made."
- "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."
From Idea to Implementation
"Go from brainstorm to sketches to HTML to coding."
- Brainstorm: "What does the app need to do? How will we know when it’s useful? What exactly are we going to make?"
- Sketches: "Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs."
- HTML: "Get something real posted so everyone can see what it looks like on screen." "Don’t write any programming code yet. Just build a mock-up in HTML and CSS."
- Code: "When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code."
Shrink Your Time
- "Estimates that stretch into weeks or months are fantasies."
- "Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time."
- "Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or re- do. Smaller timelines keep developers engaged…"
- "Next time someone tries to pin you down for an exact answer to an unknowable question – whether it’s for a deadline date, a final project cost… say ‘I don’t know… [Reframe] the question as a collaborative conversation. By learning how exact your estimate needs to be (and why), you can work together."
Hire Less and Hire Later
- "Don’t hire people. Look for another way. Is the work that’s burdening you really necessary? What if you just don’t do it? Can you solve the problem with a slice of software or a change of practice instead?"
- "If there’s no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve."
Get Well Rounded Individuals
- "Go for quick learning generalists over ingrained specialists."
- "Small teams need people who can wear different hats."
Wordsmiths
- "If you are trying to decide between… people to fill a position, always hire the better writer."
- "Being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly."
There’s Nothing Functional about a Functional Spec
- "Functional specs force you to make the most important decisions when you have the least information."
- "The more you build it, the more you use it, the more you know it. That’s when you should be making decisions – when you have more information, not less."
- "Functional specs don’t let you evolve, change, and reassess."
- "Go with a briefer alternative that moves you toward something real. 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." Then proceed as described in From Idea to Implementation.
Misc.
- "Make half the day alone time." Avoid communication and just work.
- "Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a long- winded document."
- "Avoid building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying."
- "Prioritize your bugs." "Most bugs are annoying, not destroying. Annoyances can be tabled for a bit."
