Getting Real

Leena
Continuous Delivery
4 min readNov 2, 2017

I was reading — Getting Real: The smarter, faster, easier way to build a successful web application — by Jason Fried and DHH. The emphasis throughout the book is about delivering software faster using the techniques Less is more and Keep things simple.

Less is more means — less software, less people, less code, less money, less time, less or no meetings — everything should be less. Focus on what is essential and iterate over it, rather than implementing every great idea and making it a kitchen sink, i.e., Build a Half Product, not a half-assed product.

Even though the title says web application, most of the techniques can be applied to any software product. Let’s look at a few of the ideas mentioned in the book.

Done — the magical word

Don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

Raise to done as quickly as possible by making decisions. Also accept that the decisions are temporary, just for the current context. Only when you get things done, you can leverage the power of iterations to improve further.

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.

Rather than just implementing what was asked to do, look for alternatives to do it, especially when it is hard to do. Joshua Kerievsky calls this as Bargain HuntingBargains in software are high-value features available at a fraction of the full price.

The counteroffers or bargains are essential because:

  • The resources are limited especially the time. So move to “Done” as quickly as possible.
  • Less code means less bugs and less support.

Listen to the code

Your code can guide you to fixes that are cheap and light. Pay attention when an easy path emerges.

If a task or a feature takes weeks to build or require a lot of code, then it is time to listen to the code. The code is trying to push back, and we should see whether there are alternate or a better way of doing it.

And importantly, manage your debt so that you move forward faster. It is ok to hack at times to get things out of the door. But if we don’t fix it on time, we will be paying interest (fixing hacks) instead of paying down the principal (and moving forward).

The walls between support and development

In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

A lot of software developers have a similar split. Designers and programmers work in the “kitchen” while support handles the customers. Unfortunately, that means the software chefs never get to hear what customers are actually saying. That’s problematic because listening to customers is the best way to get in tune with your product’s strengths and weaknesses.

Rather than restricting the interaction with the customer to the support team or the salespeople, everyone should know the customer and their pain points. Once we break this wall, we remind ourselves, who are we building it for and have empathy for them.

Interface Design

First impressions are crucial. If you fail to design a thoughtful blank slate, you’ll create a negative (and false) impression of your application or service.

Use Epicenter Designer — i.e., focussing on the true essence of the page and build outward. Another important thing is to design for three states, i.e., regular, blank and error.

Regular is a no-brainer. We always design for that. We consider the error to some extent. But blank is something we usually take for granted.

Alone Time

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.

Have a considerable amount of uninterrupted time to get things done. During this long stretch is when one gets into the zone and make real progress.

Meetings are Toxic

Meetings are one of the vital productivity killers for any organization. It interrupts the zone, and the progress one is making. And one takes time to come to the zone. Instead of a meeting, discuss over email or IM or Slack.

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

- Set a 30 minute timer. When it rings, meeting’s over. Period.

- Invite as few people as possible.

- Never have a meeting without a clear agenda.

Summary

I highly recommend this book to every software professional and implement as many ideas as possible. Fundamentally the message is to focus on the customer. Interact with them, design for them. Get things done by keeping things simple. Focus on fewer things and iterate.

https://www.slideshare.net/mehmetaliakyol/gettingreal-slide

--

--

Leena
Continuous Delivery

Co-founder/CTO @ PracticeNow, Bangalore, India. A strong believer of lean principles, an evangelist and practitioner of Continuous delivery