Getting Real: The Smarter, Faster, Easier Way to Build a Web Application was a great, quick read. There are plenty of fantastic bits of information packed into this book which you can view for free here. I think one reason why I liked this book so much is that I have experienced many of the points the authors mention firsthand.

My favorite highlights from the book are below.

Estimates that stretch into weeks or months are fantasies. The truth is you just don’t know what’s going to happen that far in advance.

The same theory applies to other problems too. Are you facing an issue that’s too big to wrap your mind around? Break it down. Keep dividing problems into smaller and smaller pieces until you’re able to digest them.

Make sure support queries are seen by developers. Even better, hire people with multiple talents who can wear different hats during development. The end result will be a more harmonious product.

Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions. A successful alone time period means letting go of communication addiction. During alone time, give up instant messaging, phone calls, and meetings. Avoid any email thread that’s going to require an immediate response. Just shut up and get to work.

Similarly, cut programs into smaller units. Since a large part of the problem stems from dependencies (global variables, data passed between functions, shared hardware, etc.), find a way to partition the program to eliminate — or minimize — the dependencies between units.

Design the interface before you start programming.

Design is relatively light. A paper sketch is cheap and easy to change.

The way you fight this complexity is with less software. Less software means less features, less code, less waste. The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win.

For every feature that makes it into your app, ask yourself: Is there a way this can be added that won’t require as much software? Write just the code you need and no more. Your app will be leaner and healthier as a result.

Functional specs lead to feature overload. There’s no pushback during spec phase. There’s no cost to writing something down and adding another bullet point. You can please someone who’s a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that’s how you wind up with an overloaded site that’s got 30 tabs across the top of the screen.

So what should you do in place of a spec? 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. This process shouldn’t take more than one day. Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on. Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and “feeling” before you start worrying about backend code. Get yourself in front of the customer experience as much as possible. Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.

#development#book-review