Menu
What does it take to bring Woobo to life? Lots and lots of elbow grease.
In December of 2016, I joined Woobo, Inc., a pre-revenue startup in Cambridge, MA, as a backend developer. The company was working on a smart educational companion (toy) that answers questions and inspires kids to learn new things everyday called Woobo. Woobo, a voice-interactive, AI-powered plush toy, is like an Amazon Alexa device catering to children. An iOS/Android control app (i.e. Woobo’s parent app) was also being developed alongside the toy. Woobo would come with an array of edutainment content, including stories, games, and songs. Woobo was slated for launch in about 12 months.
The initial state of development was not promising. The toy prototype was crashing after a few minutes and the backend server needed rebooting every few days. The server was monolithic and tightly-coupled, with the bulk of the important logic being in a single class. In short, the product was a long ways away from being production ready.
Adding tests to the existing server codebase would have been difficult.
Since there was no testing system in place for the server code, changes to the server had to be tested manually. Manual testing was a laborious process done via prototype toys that were in short supply. To address this issue in the short-term, I worked with our content team to establish and document a testing procedure to be used company-wide. I also asked another backend developer to develop a CLI “toy simulator” for use when actual prototypes were unavailable.
Over the long-term, a CI server, unit tests, and integration tests were needed. Adding tests to the existing server codebase would have been difficult. Instead, I created new modules that added new functionality or replaced existing ones. These modules adhered to modular design philosophies, had well-defined roles and responsibilities, and had excellent unit test coverage. Once built, these modules were wired into the existing codebase. This had the result of refactoring the existing code and adding unit tests to it in much less time than it would have taken to refactor and test the existing codebase directly. The “toy simulator” program was also modified to run integration tests. A Jenkins CI server was stood up to run the unit and integration tests for each merge request. With this testing system in place, the backend team became more productive and eventually delivered a production-ready server.