13 ms·

Blog Post Driven Development

210 points by jimiasty 11y ago

jason_shah 11y ago
This is very clever.
jimiasty 11y ago
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 11y ago
  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.
  - WojtekB 11y ago
    Hey there, Wojtek from Estimote here. Thanks for sharing your thoughts and sorry for the delay with stickers: it took us longer than expected to reach mass production. It was a lot of work (and admittedly more time than initially assumed) to get the enclosures, firmware, PCB and antenna design, and SDK just right. But we'd rather change the shipping date than compromise on product quality. While in software development you can go with the 'f--- it, ship it' mantra and fix stuff with rapid release cycle, it doesn't really apply to hardware. The initial hurdles are behind now and we're shipping a lot of Estimote Stickers daily now, burning through the backlog fast. All pending pre-orders should ship by the end of Spring, or in early Summer at the latest. You can send me your order number to wojtek[at]estimote[dot]com and I'll check what's the status and when it's going out. Cheers.
  - bontoJR 11y ago
    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 11y ago
      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.
bradleybuda 11y ago
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_backwards.html http://www.allthingsdistributed.com/2006/11/working_backward...
- omouse 11y ago
  It's the best way of setting up a clear goal. At my current job for a new project we only had marketing send over specs to some UX/UI designers and we're going to get the prototype UI sent to the devs for feedback. No idea what the exact goal of this new project is other than to keep up with the competition or to make existing corporate/enterprise users happy. Not the most ideal situation. I think writing a mission statement or press release before development would sink a lot of projects before they began and save millions.
- jimiasty 11y ago
  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 11y ago
    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
  - pm 11y ago
    I imagine it has parallels with README-driven development too.
startupfart 11y ago
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!
- heypiotr 11y ago
  Piotr, Tech Evangelist @ Estimote here. We try to mitigate any of such risks by: (a) we'll start the sprint with an outline of a blog post, a few key points, and a general theme. Then we get to work, and as we're approaching the grand finale, we start drafting the post. It actually always surprises us—when you start describing something in more detail, you bump into a whole set of "hmm, we didn't think of that", "this could use better docs", "oh wow, that part really is exciting" etc. So it does us a ton of good in terms of polishing the feature we're about to release, but at the same time doesn't block us from moving forward with the implementation. (b) but really, the rule we try to live by the most is to ship fast and often. A feature doesn't need to be perfect, we're shooting for an MVP. Sounds like a cliche, I know, but it works great for us. Long gone are the days when we'd debate, "maybe a few more RESTful endpoints for these new analytics, maybe a few more filters". Now we'll just ship it and start measuring traction & listening to feedback. If people want more, great, if not ... uh, at least we didn't waste time and can get back to the drawing board (:
- tspike 11y ago
  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.
neduma 11y ago
Readme driven development - http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel...
- yitchelle 11y ago
  The corresponding HN discussion https://news.ycombinator.com/item?id=1627246 https://news.ycombinator.com/item?id=1627246
mitchtbaum 11y ago
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_Goffman https://en.wikipedia.org/wiki/Impression_management#Erving_G...
ninjakeyboard 11y ago
At first I laughed but then I got it.
antrix 11y ago
On a lighter note, Conference Driven Development: http://devdriven.by/conference/ http://devdriven.by/conference/
ams6110 11y ago
So vaporware is a development methodology now?
deleted 11y ago
[deleted]
burkemw3 11y ago
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.
burkemw3 11y ago
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 11y ago
  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.
fibo 11y ago
Imho the post should be a draft, or private until the tasks are done
- heypiotr 11y ago
  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.)

210 points by jimiasty 11y ago

This is very clever.

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 11y ago
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.
- WojtekB 11y ago
  Hey there, Wojtek from Estimote here. Thanks for sharing your thoughts and sorry for the delay with stickers: it took us longer than expected to reach mass production. It was a lot of work (and admittedly more time than initially assumed) to get the enclosures, firmware, PCB and antenna design, and SDK just right. But we'd rather change the shipping date than compromise on product quality. While in software development you can go with the 'f--- it, ship it' mantra and fix stuff with rapid release cycle, it doesn't really apply to hardware. The initial hurdles are behind now and we're shipping a lot of Estimote Stickers daily now, burning through the backlog fast. All pending pre-orders should ship by the end of Spring, or in early Summer at the latest. You can send me your order number to wojtek[at]estimote[dot]com and I'll check what's the status and when it's going out. Cheers.
- bontoJR 11y ago
  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 11y ago
    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.

bradleybuda 11y ago

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_backwards.html http://www.allthingsdistributed.com/2006/11/working_backward...

omouse 11y ago
It's the best way of setting up a clear goal. At my current job for a new project we only had marketing send over specs to some UX/UI designers and we're going to get the prototype UI sent to the devs for feedback. No idea what the exact goal of this new project is other than to keep up with the competition or to make existing corporate/enterprise users happy. Not the most ideal situation. I think writing a mission statement or press release before development would sink a lot of projects before they began and save millions.
jimiasty 11y ago
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 11y ago
  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
- pm 11y ago
  I imagine it has parallels with README-driven development too.

startupfart 11y ago

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!

heypiotr 11y ago
Piotr, Tech Evangelist @ Estimote here. We try to mitigate any of such risks by: (a) we'll start the sprint with an outline of a blog post, a few key points, and a general theme. Then we get to work, and as we're approaching the grand finale, we start drafting the post. It actually always surprises us—when you start describing something in more detail, you bump into a whole set of "hmm, we didn't think of that", "this could use better docs", "oh wow, that part really is exciting" etc. So it does us a ton of good in terms of polishing the feature we're about to release, but at the same time doesn't block us from moving forward with the implementation. (b) but really, the rule we try to live by the most is to ship fast and often. A feature doesn't need to be perfect, we're shooting for an MVP. Sounds like a cliche, I know, but it works great for us. Long gone are the days when we'd debate, "maybe a few more RESTful endpoints for these new analytics, maybe a few more filters". Now we'll just ship it and start measuring traction & listening to feedback. If people want more, great, if not ... uh, at least we didn't waste time and can get back to the drawing board (:
tspike 11y ago
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.

neduma 11y ago

Readme driven development - http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel...

yitchelle 11y ago
The corresponding HN discussion https://news.ycombinator.com/item?id=1627246 https://news.ycombinator.com/item?id=1627246

mitchtbaum 11y ago

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_Goffman https://en.wikipedia.org/wiki/Impression_management#Erving_G...

ninjakeyboard 11y ago

At first I laughed but then I got it.

antrix 11y ago

On a lighter note, Conference Driven Development: http://devdriven.by/conference/ http://devdriven.by/conference/

ams6110 11y ago

So vaporware is a development methodology now?

deleted 11y ago

[deleted]

burkemw3 11y ago

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.

burkemw3 11y ago

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 11y ago
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.

fibo 11y ago

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

heypiotr 11y ago
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.)