
Blog Post Driven Development - jimiasty
http://blog.estimote.com/post/119525082855/user-stories-on-steroids-how-estimote-uses-blog
======
bradleybuda
This was (still is?) a big part of the development methodology at Amazon;
there it was called "starting by writing the press release":
[http://www.allthingsdistributed.com/2006/11/working_backward...](http://www.allthingsdistributed.com/2006/11/working_backwards.html)

~~~
jimiasty
Amazon did a great job with that technique and we were inspired a lot by that.
Of course companies/startups do less "press-releases" these days, so we
adopted it to blogging.

The content of published articles does help not only with team focus, but also
is a natural "deliverable" definition for UI-less products such as SDK. Blog
post simply cannot be published unless code is in the Github repo, tutorials
and sample apps are there as well as illustrations and narration communicating
new features.

~~~
tanujparikh
Tanuj from Estimote business team here. It's also super useful for my efforts.
Makes it so much easier to communicate to customers what we're working on, and
there's also the intangible benefit of impressing potential customers with how
fast and how much we ship -- e.g.,
[https://twitter.com/stevecheney/status/598905085826043905](https://twitter.com/stevecheney/status/598905085826043905)

------
jimiasty
Hi HN,

this is Jakub, co-founder of Estimote (YC S13).

As a dev-oriented company our SDK team used to ship tons of new code into our
Github repos. We realized that our SDK is much harder to productize and define
an explicit "deliverable".

Thus past few months we have applied "Blog post driven development" where the
aim of the sprint was to build, test, document and communicate SDK changes in
a form of a blog post.

This technique is working for us really well, so John who is driving that team
as a Project Leader decided to share the details with the HN community. We
hope you will enjoy it and feel free to comment.

\--- Here is also a snapshot of our recent blog posts as as a proof shipping
code with posts is working really well:

\- 5/15 - OAuth support for easier integration of Estimote Cloud into your
services \- 5/06 - Hugely improved Indoor Location SDK (4-meter accuracy) \-
5/04 - Updated Android SDK \- 4/23 - Improved beacon real-world analytics (new
SDK + API) \- 4/21 - Estimote Cloud updates (tag beacons with metadata + GPS
location) \- 4/15 - Conditional beacon broadcasting (for power saving & easier
prototyping) \- 3/24 - Fleet Management API \- 3/18 - New SDK and firmware \-
3/13 - C# and JavaScript support \- 3/04 - Support for Apple Watch \- 2/24 -
Infrastructure Sharing (open beacons to 3rd party apps/brands) \- 2/13 -
Trigger Engine

~~~
kenrikm
Is this why I'm still waiting for my estimote stickers? I'm not sure I would
ever build anything user facing with your stuff it's just not a useful
platform if you can't reliably get the product.

Edit: It's honest feedback, the down vote is unwarranted.

~~~
bontoJR
Same here, I preordered the sticker September 2014 but still nothing. I lost
faith in getting them so I moved forward with other solutions, even if I still
would like to have them around my house.

~~~
WojtekB
Hi BontoJR,

Same as above: you send me your order # to wojtek[at]estimote and I'll update
you on the expected delivery. And really sorry for the delay!

Cheers.

------
neduma
Readme driven development - [http://tom.preston-werner.com/2010/08/23/readme-
driven-devel...](http://tom.preston-werner.com/2010/08/23/readme-driven-
development.html)

~~~
yitchelle
The corresponding HN discussion

[https://news.ycombinator.com/item?id=1627246](https://news.ycombinator.com/item?id=1627246)

------
burkemw3
As a team lead, I have trouble coming up with a unifying theme for a sprint (2
weeks). My team is about 4 devs, 2 qa, a product owner, and myself (tech
lead).

If we devote a sprint to finishing a cohesive goal, I find it extremely likely
that some team members will be twiddling their thumbs for extensive periods of
time. Or that team members will need to re-work stuff to fit with a key piece,
which I consider even worse than thumb twiddling.

Do other teams experience this? How do you deal with it?

I try to have 1-2 big goals (stories) for the team in a sprint, and a few
smaller, unrestricted ones as well. If we get blocked on the bigger stuff, the
smaller stuff is ready to get knocked out.

~~~
tspike
If you're accomplishing cohesive, important goals with your sprint, why do you
care about thumb twiddling or some refactoring?

If those doing the thumb twiddling are important team members who are
tangential to this sprint, why not offer them a bonus vacation or something
else morale boosting that doesn't require their butt to be in a seat when it's
not necessary?

If they're not really helping you accomplish _any_ important goals, why are
they on your team?

All that said, it sounds like you've already struck a pretty good balance
between accomplishing big goals and taking care of small but necessary stuff.

------
burkemw3
I avoided this article for a while because I thought it was going to be about
mediocre devs copying-and-pasting code from development blogs into
'enterprise' software and the impact that it had on morale, or culture, or
whatever.

What a pleasant surprise!

It did quickly remind me of Amazon's 'press release driven development'. I
appreciate the desire to promote, but I wish some popular, public art was
credited.

------
mitchtbaum
I like this approach's writeup for several points it makes. 1) Planning ahead
and framing your definitions through a deep engagement helps developers focus
through understanding their work and it adds to their motivation. 2)
Consistent engagement with users helps with adoption. 3) Code is only part of
the picture, and a release produces ongoing opportunities for improvement.

In terms of 1, within Drupal's developer community, I remember an aphorism,
"Talk is silver, code is gold", which served to promote valuable productions
over endless discussions. Then, someone took that and a general feeling of a
need for foresight before hasty implementation and said, "Talk is silver, code
is gold, and planning is diamonds."

In terms of 2, for free software and community projects in general, I get a
sense that this approach aligns with stakeholder engagement[0] toward
empowering active developers with broad community feedback through timely
awareness and helps community cohesion, as well as user empowerment.

On a brief theoretical view of this aim to align shared interests, this
approach strikes me as an appropriate response to dramaturgical awareness. In
terms of impression management[1], I get a sense that contributors generally
want users to see them as involved for good cause and effect, and users want
to be seen as grateful, willing participants (hence comments sections on
release posts with floods of thank yous). This outlet seems like one way to
deepen this two-way information flow.

0:
[https://en.wikipedia.org/wiki/Stakeholder_engagement](https://en.wikipedia.org/wiki/Stakeholder_engagement)
1:
[https://en.wikipedia.org/wiki/Impression_management#Erving_G...](https://en.wikipedia.org/wiki/Impression_management#Erving_Goffman)

------
antrix
On a lighter note, Conference Driven Development:
[http://devdriven.by/conference/](http://devdriven.by/conference/)

------
ninjakeyboard
At first I laughed but then I got it.

------
fibo
Imho the post should be a draft, or private until the tasks are done

~~~
heypiotr
Wholeheartedly agree! We never publish a blog post before the feature actually
is live. We want people to be able to immediately go ahead and play with the
it—which is also why we treat these posts as mini-readmes, i.e. we always try
not only to paint the story behind the feature, but also do a short intro to
how to get started (code snippets etc.)

------
jason_shah
This is very clever.

------
ams6110
So vaporware is a development methodology now?

------
startupfart
Isn't there a risk by the time you finish the blog post, someone has posted an
even newer JS or Go framework in Grithub, and you have to simply replan the
whole tech to use it!

~~~
tspike
I have a feeling you didn't even read the article and instead interpreted the
headline to mean "we use whatever technology generates lots of blog posts,"
which was my interpretation too, prior to reading the article which is
describing what's actually a pretty good approach.

