Become Efficient or Die: The Story of BackType (YC S08) | Hacker News Reader

Become Efficient or Die: The Story of BackType (YC S08)

slideshare.net

125 pointsnathanmarz21 comments

"Don't add process until you feel the pain of not having it."

Great set of slides, thanks for posting this.

That was the true spirit of Agile. Which unfortunately was lost in the Chasm: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

Lean Startup seem to be more immune to it, as the very need of the process is filtered through the process (do you really need it? test it!)

"Don't add process until you feel the pain of not having it."

Excellent phrasing of what I've been preaching in our startup all along. We apply this to every angle of our business and I find this is very, very good advice for startups.

And it's not just for software development, either! Need an order processing system? No you don't — you can handle things manually at first, thus learning what you really need. Need a CMS? No you don't — the bugtracker you use for your software can probably help you enough in the beginning. Examples abound.

Follow this philosophy and you'll build a lean company. What's even better is that once you actually do add process (or buy external solutions, or hire additional people, etc), you'll know what you're doing, because you will have learned the real requirements.

My favorite part of the slides: "First, make it possible. Then, make it beautiful. Then, make it fast."

Having personally been bitten by doing each of these out of order, they make a lot of sense.

It is risky to put design second.

Check the slides -- that's not what he's talking about.

I think the point is that it is risky to design before you fully understand the problem you're solving. From my interpretation of the slides, they are often working on tasks they have little experience with. Instead of spending time thinking about potential design issues (which may or may not exist), build something that works and the patterns which the feature requires will emerge, enabling an elegant design afterwards.

I love the "garbage collection for your codebase" thing. Nice simple approach for moving things from the "should" pile to the "done" one.

They're using a stop-the-world garbage collector. Surely we've come further than that in the past few decades?

Suffering-oriented programming: A great mantra for startups. If you don't face the problem yourself, then there is no point in building software for it -- chances are no one else has it too.

I agree. Only when you know how the pain feels, you are capable to create products that alleviate that pain.

Actually, that's not what he's talking about. He's saying that they only do something about lack of process or messy code or whatever when it starts to hurt them. It's strictly internal.

Ran into a lot of problems with Neo4J and rewrote it later using Sphinx

Really? I'd love to hear more about this.

Nice read, really good app also... btw, clojure rocks!

Does anyone have a direct link to the PDF file?

Great one. Subscribed to your blog, there is alot of useful articles to read there.

"3 employees, 2 interns, 1.4M in funding"

What will the money be used for? Are you still trying to reach product/market fit?

I'll bet the cost of 1-200 machines is adding up pretty quickly.

The money will be used to fund product development so we reach product/market fit. It will be used mostly for growing the team. Our burn rate is actually quite low right now since we generate significant revenues that support most of our infrastructure.

Having to click 64 times to get through a brief story is not efficient.

Which is why I like to be able to download a SlideShare item and then view the PPT as a pdf.

But this one DLs to an OmniOutliner doc ?!? Unfortunate. And author's site (nathanmarz.com) does not even mention this presentation. Can you help us out Nathan?

Reply on news.ycombinator.com