Sprint 2 is in the books

Heroku Pipelines

We finished Sprint 2 yesterday, and a bit of reality sunk in. It was a bit of rainbows and unicorns the first week, but now we’re getting down to business. We’re starting to flesh our our process quite a bit, and continue to add to our getting started guide (importance of documentation), but we ran into a couple of snags during our sprint that requires some action. However, first, before getting into the hard bits, here are some highlights of what we accomplished for last sprint

  • Using Channels to send thermostat data from our Digi gateways
  • Integration with Auth0 on front-end UI, and integration using JWT for our backend API
  • Reach Prototype working with our backend API
  • Built up “Facility” objects to represent buildings where devices would be in
  • Explored alternatives to building our own Device backend, specifically with AWS IoT and API Gateways
  • Built up our core getting_started guide, and added more info to our code markdown
  • Implemented Heroku Pipelines for our Continuous Delivery process for our backend API

It’s not perfect and that’s ok

Now, we can sit here and talk about how amazing it is, but that’s not really representative of what happens in development. You will run into trouble, your customers will discover issues, bugs will happen, and your system will crash. This is all expected and frankly if its not, then no one is using your software :). Here are some of the major items we ran into

Competing Priorities
We are a startup, and there’s a lot of stuff going on. We have our existing product, and while we’re trying to build up some new services, we still have to maintain some of the previous system, which creates additional issues we have to manage. Then we’re exploring a new market area, and that’s diverted some attention to another area. So now we have various things that are all “high priority” and how do we go about balancing them, and deciding which one to work on? Well, we’re still figuring that out. We just have to take one issue at a time, figure out which ones are the most critical and just address them. This is where Continuous Delivery really helps us here, as we can focus on one area, and then pick right up, and not interrupt a flow. Even if we took a whole release off to work on bugs, it’s ok.

The infamous rabbit hole
As you may know, we’re learning a lot of new things, so there’s a bit of a learning curve for various technologies we use. Due to this, we can get stuck for quite a bit of time trying to wrestle with a new system or code library. We ran into this with React + Phoenix + Brunch (one of us spent a whole weekend and then some troubleshooting). We had this with JWT and how to use it, and then there’s general “learning Elixir” and “learning Phoenix”. Even some of us were exploring using new editors like Sublime or Atom.io and that can take away from us as well. Really there’s always a balance. Learning, failing, trying again is the natural process. We should always account for this time, BUT, the trouble arises when you are too deep into something, and the branch age gets a bit long, or you’re banging your head for a tad too long. The suggestion here is to WALK AWAY. I know as developers, its very hard to do that, but sometimes it has to be done. The “Competing” priorities could actually benefit from this. Just set that nasty piece of code aside, and work on something else. Or even ask another colleague to “tag in” and help out, while you may help out with their issue.

Gathering Feedback
With a new product, its easy to just build a bunch of stuff, but the faster we get user feedback the better. Gathering this feedback, and then incorporating into the development process is very important, thus creating the true “agile development cycle”. We’re still figuring this process out, but at the minimum we will need to incorporating support/customer interaction tools and metrics tracking. Now, how do we go about delivering some of the features, do we use something like Balsamiq or InVision? Or do we just build it into the product and get feedback? At this point, we’re still starting out and our team size is small enough that we can just build as we go along. It’s not to say tools like Balsamiq or InVision isn’t needed, but it doesn’t make sense at this moment. This is one of our guiding philosophies of “do we need it right now”? We know we need to scale our database, and build up a better demo model, but do we need it right now? We’re just taking it one sprint or one day or even one hour at a time, and that’s ok.

We’ll be posting some info on how we got past that nasty Heroku+Phoenix+React+Brunch nastiness and some of the other learnings, so stay tuned!