I think you might be misleading here. Your post about starting with a friend triggered quite a lot of emotions, so its staying not only because of its length.

But you're right that longer posts are more likely to 'catch' the reader

I really like your post, I commented it http://danieltenner.com/posts/0005-starting-up-with-a-friend... . 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...

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 :-)

Problems with releasing early and often, eh? Have you tried Erlang?

Sorry -- I'm still getting that out of my system.

Seriously, as smombat points out, posts are much better if you tell the story of how you got to where you are and why you made the decision you did. That gives the rest of us some context. For the most part, broad, sweeping statements are false. Especially in IT, where there's too many edge cases. So the details of your particular situation are what adds value to the reader.

I didn't want to write a "statement" and that's why I said that it failed for us. I just wanted people to think a little before they release early and often. About how could it fails for them.

Yes, and to get people to think about how it could fail for them, you need to paint a picture in their mind of how it failed for you -- so they can emotionally connect. Otherwise you're just writing one-line platitudes: think about how you release, be sure to debug, think about design before coding, etc.

It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.

It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)

That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.