Book highlights: “Getting Real” by 37signals

Run on limited resources and you’ll be forced to reckon with constraints earlier and more intensely. And that’s a good thing. Constraints drive innovation.

Fix Time and Budget, Flex Scope

Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, and scope window. Leave the magic to Houdini. You’ve got a real business to run and a real product
to deliver.

The ability to change is key. Having everything fixed makes it tough to change. Injecting scope flexibility will introduce options based on your real experience building the product. Flexibility is your friend.

How does a project get to be a year behind schedule? One day at a time.

Mental models/mindsets:

Just-in-time thinking
Multi-tasking team members
Embracing constraints, not trying to limit them
Less software, less code
Less features
Small team size
Simplicity
Pared-down interfaces
Open-source products
Open data formats
An open culture that makes it easy to admit mistakes

Don't over-optimize. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system

Work from large to small.

The best designers and the best programmers aren’t the ones
with the best skills, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made.

HIDDEN COSTS OF 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…
16. Check to see if help text needs to be modified.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is affected.
22. Launch.
23. Hold breath.

I do not think I’ve ever been involved with a software project — large or small — that was successful in terms of schedule, cost, or functionality that started with a long period of planning and discussion and no concurrent development. It is simply too easy, and sometimes fun, to waste valuable time inventing features that turn out to be unnecessary or unimplementable.

Hiring

Find someone who’s enthusiastic. Someone you can trust to get things done when let alone. Someone who’s suffered at a bigger, slower company and longs for a new environment. Someone who’s excited to build what you’re building. Someone who hates the same things you hate. Someone who’s thrilled to climb aboard your train.

Observe whether a potential hire asks a lot of questions about your project. Passionate programmers want to understand a problem as well as possible and will quickly propose potential solutions and improvements, which leads to a lot of questions. Clarifying questions also reveal an understanding that your project could be implemented thousands of different ways and it’s essential to nail down as explicitly as possible exactly how you imagine your web app working. As you dig into the details, you’ll develop a sense of whether the person is a good cultural match.

Hire good writers. That’s because 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. And those are the qualities you need. Good writing skills are an indicator of an organized mind which is capable of arranging information and argument in a systematic fashion and also helping (not making) other people understand things. It spills over into code, personal communications, instant messaging (for those long-distance collaborations), and even such esoteric concepts as professionalism and reliability.

Encourage programmers to make counteroffers.
You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.