Orro Integrations with Third Party Smart Devices
Why we built this
At Orro we believed in working with other brands that create interesting and innovative solutions in the home automation space. As companies of many sizes and ages released smart devices, we added support for many of them so those could become an extension of our Smart Living System.
Integrations allowed for:
Remote control capability to control all smart devices in the home through the Orro Switch and/or the client apps.
Automated decisions based on Orro’s algorithms and user preferences, executed on the third party smart devices.
My Role
Web Developer
Feature Driver for some integrations
Tech Stack
Client side: Swift, Android and JavaScript
Switch application: Kotlin
Backend: Kotlin, Python
Cloud: AWS
Development Process
We added 10 categories of smart device integrations across 20 providers over a period of 2.5 years. The development process for these features and software features in general evolved overtime, starting with the selection of which integration and/or new provider to support next. This decision was informed by what the early adopters were providing feedback on and what our own user base was requesting.
Steps:
Orro sees rising adoption for a smart device in the market or current Orro users request a feature.
Product owner (hat worn by the CEO for the majority of the features but open to anyone who wanted to champion an idea) writes up a brief listing desired use cases and their priority.
The brief document is reviewed asynchronously and improved upon from feedback by Software and Design teams.
The brief document is discussed in a live meeting with Software, and Design teams (and occasionally the Support team, to be another voice for the user).
The brief is finalized. Design team creates wireframes for the assigned engineer to ponder upon.
The engineer works on an estimate of effort for different combinations of implementation options. This document is reviewed, discussed and finalized and an implementation option is selected. The tradeoffs are almost always between the time cost and the feature richness for the first version that needs to be shipped to production.
The engineer works on a detailed architecture document and QA requirements that are reviewed, discussed, and finalized.
Work is scheduled for an upcoming sprint.
At any given time 5-6 features would be in various stages of this process and at least 4 features would be ready to be worked on. In the software team the work mix consisted of 70% active feature development and the remaining split between feature driving, research and architecting new features, support and general maintenance.
Feature development work varied from 1-4 weeks. The full life cycle of a feature idea being picked up, developed and shipped took between 8 -10 weeks. We definitely moved fast like any startup but also focused on not breaking things as much as possible.
In the Software team we rotated through certain responsibilities like managing this development process at the company level - keeping track of the features and their stages in the development pipeline, corralling the stakeholders and running the review meetings. This was one of the secondary hats I enjoyed wearing often.
Constraints & Challenges:
With every integration that we added - we learned new lessons and adapted to the design inconsistencies of the external APIs, products and services.
Over time our codebase became more reusable and adding new providers came down to adding a line in the database and adding a new integration needed 80% less coding than the first integration.