This is a collection of personal notes for Getting Real by 37signals. For more, read part one and part two.

The customer is not always right. The truth is you have to sort out who’s right and who’s wrong for your app.

If I had asked people what they wanted, they would have said faster horses.
Henry Ford

Tables were in use long before iPad appeared on the market. Yet, ‘the bigger iPhone’, with the same shortcomings, revolutionized (from the market perspective) how we use tables now.

Create a great app and then worry about what to do once it’s wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens.

Don’t write a book, write a single page. Write a paragraph. Write a sentence. Day after day. Don’t run a marathon. Don’t start with 10k. Don’t start with 5k. Don’t start with 1k if you can’t run that distance. Start with marches. Not possible? Crawl!

Don’t turn your diet over. Replace unhealthy habits with healthy ones. Step by step. That’s it. Enjoy the process without waiting for the end goal to come. Progress is about adjusting here and there. Build the app, write the book, run the marathon, but fall in love with the process.

They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit.

It’s not arrogant. I’ve seen (and planned) many tasks that were supposed to be tackled in four hours. Software development is not a factory that churns out features like a flick. New feature always takes time. Time to plan. Time to test. A few rounds of code reviews. Keeping the feature branch in line with master branch. Refactoring tests, and so on.

I can understand that writing features is a kind of a challenge. In web development it is easy to be busy. There’s always something to be honed, something that can be tweaked-up. Senior developers, from what I’ve noticed, are more pragmatic about estimations. It’s said that with time and experience task estimation goes through the following stages:

  • It’ll take ten minutes
  • It’ll take at least two hours
  • It’s possible within a day
  • Do we need that feature?

It’s always easier to say ‘yes’ and go with what most people would opt for.

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.

Sometimes all scrum meetings piss me off. Sometimes all work unrelated with coding seems to be a waste of time and energy. I realized, though, that some meetings can bring some human factor into our daily and highly focused on performance work. For example, when morales are low and work does not seem to flow, a meeting with a scrum master can turn the situation over. Reminding of how much has been done so far can boost the morales.

Customers want everything under the sun. They’ll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.

Some time ago GitHub featured Pull Request templates. At the beginning I did not see any value in that until I wanted to report a bug in some open source repository. When I was flooded with questions and steps to cover, not only did it reminded me of KDE bugzilla, but made me realize that time is very precious.

Skipping some steps would require other people to remind me of adding them anyway. Incomplete issue could hang for weeks, making others wonder if this is closed or not. That issue would then have to be reviewed periodically by someone. That person, in order to make sure that the issue is still important would need to send me a notification and ask if the problem still persists. So, if you want a new feature, code it and create a pull request. Noticed some bug? Report it by making deliberate effort to cover everything that the project maintainers require.

Stories, wireframes, even HTML mockups, are just approximations. Running software is real.

Keeping docs, maintaining a wiki, or lists of ‘small tasks to be done sometime soon’ (GitHub wiki / Trello / whatever) gives a sense of a control, but apart from wasting time for this kind of documentation, it becomes outdated within a week.

Now I’m more inclined into writing specs and generating a documentation out of the source code; they bring more value and you will know where to find it. By the way the todo: works the same way. If you don’t have time to do it, don’t you add that todo mark. Move on. Otherwise they will pile up and nobody will take care of them.

Iterations lead to liberation

No project can be regarded as finished. You can only set some deadline in order to ship a product. Then you can move on to another iteration.

You’re faced with a tough decision: how many messages do we include on each page? Your first inclination may be to say, “Let’s just make it a preference where people can choose 25, 50, or 100.” That’s the easy way out though. Just make a decision.

Preferences are a way to avoid making tough decisions

For many years I was using KDE desktop environment. When version Four came out, it wasn’t even called Four but Four Zero. Each new version was released in a 6-month cycle if I remember correctly. Each new version brought multitude of features that were supposed to amaze folks of how much KDE can be customized and how it is powerful in comparison to Gnome. Wobbly windows, 3D cubes, fireworks and whatever you could imagine. I could tweak-up every single element in every single part of the desktop.

The sad part was that with new features, new bugs pilled-up. New bugs resurrected and made the whole user experience not that smooth as it could have been. I’ve been not using KDE for a few years, but I’m pretty sure that the developers betted on stabilization than all-the-time customization.

KDE is open source software. As it’s maintained mostly by the community, new features can added like that. Anyone can add something new and amazing. Business software wouldn’t work like that. Still I believe that when open software goes well with business, the end user wins.

It’s so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.) To me, ideas are worth nothing unless executed. They are just a multiplier.

Ideas are cheap, as my colleague often says. The ‘vision’ that you may hold in your mind can be another breakthrough, but until you can prove it, you’re wasting other people’ time. Until you get the shit done, idea is, well, shitty.

I think that one can compare ‘get-money-and-build-start-up’ and projects on Kickstarter. Campaigns that collected millions are not blueprints or sketches floating in the deep space. Most often inventors have working prototypes and only need money to finish the project.

When I wrote the book Agile Web Development With Rails, there was a lot of pent up demand among developers: give us the book now – we want to learn about Rails. But I’d fallen into the mindset of a publisher. “It isn’t ready yet,” I’d say. But pressure from the community and some egging on from David Heinemeier Hansson changed my mind. We released the book in PDF form about 2 months before it was complete. The results were spectacular. Not only did we sell a lot of books, but we got feedback – a lot of feedback. I set up an automated system to capture readers’ comments, and in the end got almost 850 reports or typos, technical errors, and suggestions for new content. Almost all made their way into the final book.

Ship early, ship often. I can see great potential in the way technical books can be written as if it were a open source projects under versioning control system. This rough and personal notes, can be, for example, a source for some e-book.

This is the second time I’m reading Getting Real. I’m also going to give Rework another try and publish notes the same way I’m doing now. Getting Real and Rework are perfect examples of how many word-fillers you can cut out. Short chapters do not leave space for bla bla bla not to mention how those book can be perfect use-cases and sure-fire way to write a successful books.

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.

In ‘Getting Thing Done’ David Allen writes that our mind does not have the notion of time. It does not matter if the task to be done is ‘taking rubbish out’ or ‘taking over the world’. He also quotes one of his seminar attendees that compared ‘not brain dumped project’ to something amorphic. Only when you move the idea into paper, sketches will you be able to estimate more accurately.