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
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.
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.
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.
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