

Releasing early and often... how it failed for us - dan_sim
http://behindtheclock.timmyontime.com/post/85810187/releasing-early-and-often-how-it-failed-for-us

======
mtkd
Not much substance in that post.

However you need to control events and not let events control you. If you
react to every tiny issue reported you will end up in a cycle of release-
issue-fix-release.

If the issue is only affecting a minority of customers and it's not critical
for security - park it - and keep on with the feature plan.

You can't please all the people all the time.

~~~
dan_sim
I'm testing small posts. Not everybody has the time to read a long post with
infinite details about a story when the conclusion is "you lose the grand
scheme of what you’re building" and that you sometimes should "wipe your
entire work".

~~~
swombat
Tip: keep the long posts, with a good hook at the beginning and a summary at
the end with key points highlighted at the end.

Example: [http://danieltenner.com/posts/0005-starting-up-with-a-
friend...](http://danieltenner.com/posts/0005-starting-up-with-a-friend.html)
(still on the HN front page)

~~~
dan_sim
I really like your post, I commented it
[http://danieltenner.com/posts/0005-starting-up-with-a-
friend...](http://danieltenner.com/posts/0005-starting-up-with-a-
friend.html#comment-7098609) . But even then, I'd say that I read 80% of it
(most time, I read less than 50%). I just said to myself why not cut the post
to have a shorter one that people will enjoy a moment. Turned out I was
(maybe) wrong. I'll definitely give it another try though...

~~~
swombat
As a counter-example, I tried to be brief as well in another post on there
(<http://danieltenner.com/posts/0003-impossible-is-a-step.html>) and that one
didn't work out very well - when I asked people why they didn't like it, they
said it was too short and lacked substance/examples.

I'm a big fan of keeping things as brief as possible, but from what I can tell
it's not the best format for the web. I've only seen it work for people who
have huge followings already (e.g. seth godin). Even there, most of their
posts don't take off...

I could be wrong of course! Good luck to both of us :-)

------
swombat
This seems like a poor argument against "release early and release often".
First of all it's not all that coherent or structured, and secondly it's very
lacking in actual discussion of what went wrong.

It sounds like the author's team got stuck in a bug-fixing cycle where each
release caused enough new bugs to fill the next iteration with bug-fixing
work. Were they using automated testing? Was the development team good enough
to adapt to a rapid release cycle (not everyone can do it)? Too many unknowns
to comment on the author's experience...

It's also worth pointing out that nobody said a rapid release cycle was easy.
It's hard to keep the vision and the details in mind. As they say,
"Programming is hard, let's go shopping".

------
kristiandupont
I frequently hear these two arguments against releasing early and often: 1)
You will have a primitive product with bugs which means that the people who
see it will be turned off and not want to come back later. 2) The argument
made in this post, namely that you loose focus and end up putting out fires
and implementing feature requests all the time.

As for #1, I just think that it matters very much because the group of early
adopters is going to be very small anyway, unless you do some hyped launch
like Cuil. Therefore, loosing a couple of users for good can be a small price
to pay for the highly valuable feedback that you are bound to get.

#2 is something you have to be concerned about but that doesn't mean that you
have to let it control you. And once something is launched, you are bound to
get feedback anyway, so it really only applies to the "release early"-part.

------
lacker
Looks self-referential. I think this blog post was released too early, before
it got any content.

~~~
dan_sim
I laughed, I must admit.

------
markessien
Releasing early did not fail for you - it showed you what was wrong with your
product. If you had done all those tweaks in silence and expected to come out
to a great roar of approval, how do you think you would have felt when faced
with a great wall of don't-care?

You released, you saw what the problems were, and now you hopefully have
learned from the experience, and can go in a better direction. Just be sure to
evolve, do not scratch and try to start afresh.

~~~
flamontagne
Ehm, no. Releasing early did fail for us. The idea was not mature enough, the
"puzzle" wasn't completed but we started developement and released too early.

~~~
markessien
Did you ever consider that the idea was wrong? And that the 'fail' was just
telling you that the idea was wrong?

~~~
flamontagne
Yeah we did consider that. But we arrived at the conclusion that the idea was
still great.

~~~
markessien
Do you have numbers to prove that your idea is great? Having been launched for
a while, it should be pretty easy to rearrange traffic data in such a way that
it gives you a benchmark as to how relevant your idea is to people.

(Forgive me, but I like using numbers as a basis for decisions)

~~~
flamontagne
We know that idea is relevant because 1) WE find it relevant and 2) by the
initial comments we are receiving from our users. Most are in love with the
idea... but after that they feel let down. The problem is how the idea is
executed, not the idea itself.

------
10ren
For release early, release often, you need to know where you are going.

It works especially well if you have a model to copy: Microsoft Windows 1.0,
2.0, 3.0 was based on the Macintosh. Linux was based on Unix.

Or you can have clear vision that you are working towards - in this case, the
model you are copying is imaginary.

I guess that's the "Grand Scheme" the article is talking about. You do have to
have a way to keep that in mind, and build towards it. You can do this by
giving selective attention to the feedback (bug reports, feature requests,
complaints) that leads _towards_ your Grand Scheme. This also builds a user
base that is aligned with what you want to do (by encouraging those people,
and turning off the others). Then your user base supports your vision, instead
of undermining it.

You are the captain.

------
dan_sim
I wrote the extented version : <http://news.ycombinator.com/item?id=513655>

------
flamontagne
Like Dan, I think that releasing early and often is a bit overrated as a
concept. It was started by 37signals and people have a tendency to read their
stuff like it was their bible.

There is definitely a danger to release early and often : You have less time
to think about your core idea. If you embark yourself in a quick release cycle
without precautions, you have greater chances to forget about the product as a
whole and its evolution. This is what happened to us. Now you could say that
it happened to us just because we are stupid, but it would be more productive
to start cogitating on the implications of bold statements like "Release early
and often".

~~~
gnaritas
It was not started by 37signals, it was popularized by them. The practice has
been around much longer as part of extreme programming, as have most of the
things they preach.

The 37signals guys are great marketers but about the only thing unique to come
from them, the only practice they actually created, was convention over
configuration as a core principle. Everything else they just picked up and
repackaged from existing extreme programming principles.

~~~
spolsky
It's way earlier than Extreme Programming. Believe it or not, it was once
considered a part of Object Oriented Programming. Here's an article from IBM
Systems Journal 1993 where I first learned the idea of ship early and often:

<http://www.research.ibm.com/journal/sj/323/ibmsj3203E.pdf> [PDF]

~~~
jhancock
I'll add that "Extreme Programming" and other forms of Agile is mostly a
buzzword/re-branding to wrapper quite a few "best practices" from the OOP
world. Which is appropriate since so many of the early agile manifesto folk
were the same ones that pioneered the OOP best practices.

------
cmos
I liked the 'timmyevolved' page.. the music was good and it built up mystique.
However, I'm going to forget all about it in another hour or so..you'd better
get some attention when you relaunch, and even put out a couple more
announcements along the way hinting at what the new site might do.

(then again, it might not matter since I never knew what the old site did)

~~~
flamontagne
Glad you liked the trailer and thanks for your insights.

------
jfarmer
"The often part of release early and often, went really bad. Once that
TimmyOnTime was out, we had feature requests, bugs and other critics."

I don't see how this is ad. That shit is DATA. Data informs your future
decisions. You're free to incorporate it or ignore it at your will.

Why, you can even act as if the "release" never happened in the first place.

------
teej
I think it's a great idea to occasionally step back, throw away some of your
work, and start over. That being said, it's hard to say where they draw this
lesson. This post is thin on the details of "how it failed for us".

------
cuerty
Another example of another form of procrastination.

Release often is about getting exited with your product, I about bugfixing as
exiting.

------
diN0bot
what is timmyontime?

~~~
c3o
Time tracking over IM bots. I really like the idea (and the nonexistant signup
process!), gonna see how well the implementation works over the next days.
<http://www.timmyontime.com>

------
alanthonyc
you need to separate the principle from the dogma...

apparently, you released too early, too often

