• The Unintended Cost of Shipping

    Tuesday, September 30, 2014

    9/30/2014– Jon McKay

    Note: The opinions voiced in this retrospective are Jon’s. Other Technical Machine team members may or may not share the same thoughts.

    The Low Point

    Anyone who has started a company will inevitably tell you “it’s an emotional rollercoaster”. True to the maxim, Technical Machine hit its first real valley just after we shipped Tessel, a crowdfunded, JavaScript programmable microcontroller platform. The months of June and July at Technical Machine were the most difficult times I’ve experienced as both an engineer and as a CEO.

    We had some legitimate problems: when we shipped we had nearly a third of customers contact us with fulfillment issues, we missed a critical GPS module hardware issue, and most of our software testing infrastructure was decrepit when we shipped rushed code, to name a few. But those issues aren’t difficult to solve. Those issues have been more or less fixed with a combination of engineering time and money.

    But we had a scarier issue: our motivation to keep pushing was dwindling. Before shipping, we had this single, unifying, direction-full goal of getting this novel product out the door. But after Tessel was in the hands of users, all there was to do was feel burnt out from the 16 hours days, fix those difficult bugs that had been haunting us (and now our customers) for months, and try to track down lost shipments. Sure, there was the joy of hearing from our customers how much they loved our getting started experience but, between those snippets, it was hard to not feel demoralized. Surely, there had to be more to it than this?

    During my one-on-one meetings with everyone on the team, they each independently explained that they felt that we were now directionless. Why wasn’t I providing more direction for the company? “We need to be working on the next thing by now”, they all said. What was the grand vision for Technical Machine?

    The truth was, I didn’t have one yet. I felt that this was our time to learn as much as we could from our product being released into the wild. I thought that the future of our company depended on what our customers taught us about how they build hardware with Tessel.

    It turns out, as is usually the case, I was partially right and mostly wrong.

    The Cause

    We started Technical Machine with the idea that developing hardware should be as easy for a web developer as deploying to a server. Whether or not it’s possible, it is an ambitious technical and social engineering challenge. These types of lofty goals attract the type of people that want to work on very hard, unsolved problems every single day. We were all comfortable working towards solving looming, unanswered technical questions. But after we shipped Tessel, there weren’t many architectural questions left. We had proven that JavaScript and Node on microcontrollers could make for a great prototyping experience; all that was left was (a lot) of polish.

    Myself excluded, the entire team consisted of “research-heavy” engineers. Engineers who want to build entirely new things as quickly as possible and aren’t as interested in polish. Nobody on our team strongly identified as the type of engineer who likes to sit down and make a code base shine. The desire to fix bugs and maintain the product after it was released was not as high as developing a prototype to begin with.

    To compound the problem, we had little testing infrastructure in place while developing Tessel, so our product was buggier than it could have been (an artifact of having just graduated from college, where testing code was rarely discussed or practiced).

    In short, there were more bugs to fix and nobody interested in fixing them. Asking our engineers to continue preening over our existing code base after months of working on it wasn’t making anyone happy or productive.

    At this point, we had two related but distinct issues: the company had little sense of direction, and what we did have to work on wasn’t making anyone excited to come in to work.

    The Lessons

    In an effort to give our company more direction, we started having long brainstorming sessions about what we wanted to build and where we wanted the company to go. We talked about what we had learned from customers using Tessel in the wild. We talked about what we were interested in as individuals.

    Ultimately, we arrived at a couple of key points:

    • Prototyping tools and manufacturing tools have traditionally been disjointed. There has always been a leap from the device that proves out the viability of an idea and the device that eventually gets to market. Creating a sustainable funnel for customers to progress from prototype to a product at scale is a business opportunity worth pursuing.
    • As a company, we’d like to head further away from the toy/hobbyist market and closer to being a trusted provider of embedded hardware tools – not just for web developers but eventually electrical engineers and seasoned product developers as well.
    • We’re not interested in being another hardware platform that succumbs to building the “IoT cloud” to rule them all. We feel that, while cloud platforms have their intricacies, the technical and social engineering challenges are not appealing.
    • Tessel’s getting started experience is top-notch. Integrating npm with the hardware modules provides for (in our opinion) the fastest prototyping platform available. Users could go from unboxing with no hardware experience to serving pictures from the camera module in a web app in under 5 minutes. It’s important to us to continue enabling that type of interaction.
    • While we do believe Tessel is the best way to prove out an idea’s viability, it leaves the user further from a technical prototype than they could be if they used other hardware platforms like Arduino or Launchpad. Working in JavaScript and Node land doesn’t scale well in hardware because of the unavoidable consequence of working with components that are overpowered.

    Focusing our attention on Scalability

    We reframed the problem as “How can developers leverage the speed of development of JavaScript and Node while still making the transition to a technical prototype as simple as possible?”. In order to get an idea of the areas of opportunity in the space, we drew up a checklist of all the task items that have to be complete before a developer is ready to ship a product (the topic of an upcoming blog post) to get a better idea of where we can add value.

    Based on what we’ve heard from users of Tessel, one of the most important and opaque transition points from the “idea viability” stage to the “technical prototype” stage is picking out the actual components (integrated circuits, sensors, etc.) that are to be used in the final design.

    We held quite a few brainstorming sessions as a whole team but didn’t make much progress until Kevin, Eric, and I were casually discussing the hardware development process.

    Kevin, our lead firmware engineer and previously a co-founder of a hardware tools company called Nonolith Labs, started explaining an idea he had for how hardware development should be done. I’m not sure how much of it was formed before our brainstorming meeting, but it came out in a fairly cohesive stream. Kevin’s idea was largely focused on software defining hardware interfaces in such a way that it becomes possible to automatically generate more components of a hardware device.

    Imagine embedded hardware development as being composed of six levels of abstraction:

    1. Data Flow: A description of how data flows between different inputs (sensors) and output (network) blocks, as well as code blocks (JS, Rust, C, etc.) of various languages.

    2. Firmware: A verbose and precise description of machine-readable code that dictates how the hardware works at the lowest level to allow that flow of information. Boilerplate configuration code, for example, setting up registers to communicate with external memory, can be autogenerated if parts are known.

    3. Part Selection: The actual integrated sensors and integrated circuits that comprise the system. There is a dependency between the code that is generated and the microcontroller that is used.

    4. Schematic: How the pins should be connected together. If parts are known, then this becomes an datasheet scraping problem.

    5. PCB: How components are physically laid out on a circuit board. If a schematic is known and context of each signal is known (is this power, ground, a high speed usb signal, RF signal, etc.), then a PCB becomes easier to automatically route. Auto routing has traditionally been considered a bad practice and nobody has done it well yet.

    6. Manufacturing: Who actually manufactures the PCB and/or assembles the parts.

    In theory, the hardware development process could be described from any of the above levels of abstraction (besides manufacturing) and a circuit board could be generated as precisely as it was described. Each level of the process should be optimizable so that a seasoned firmware engineer could tweak the firmware or an electrical engineer could add necessary passive components and modify the size of any sensitive traces.

    The idea of “software defined hardware” resonated with the team as a solution space worth attacking. An accessible but powerful hardware development tool that would take years of development work aligned very well with the personal interests of everyone on the team. The question turned from “what are we building next?” to “how do we approach such a giant, complicated system?” Once we we were able to frame the problem around solid technology choices that could accomplish the goal of “software defined hardware”.

    As a first step towards that goal, we’d like to enable a user to program a single application in both low-level and high-level languages. This means developers can prototype an idea quickly in JavaScript, and if it proves viable, start breaking the component parts into C or Rust. It’s a much easier path to a technical prototype than starting from scratch when moving to a technical prototype.

    Tessel is just the first development board which would be the target of this new hardware development tool. Over time, we hope more and more microcontroller targets will be contributed so that our open source tool can extend past just the Tessel ecosystem. We’ll be releasing more information about this new tool as we start speccing it out.

    Maintaining Tessel

    As for maintaining Tessel’s architecture, we’ve made a huge amount of progress. By having each person in the company split their time between working towards these new engineering goals and working on maintaining the released Tessel platform, we’ve reinvigorated our collective enthusiasm for our vision. We’ve also started hiring people who would be well-suited for support positions. In that vein, we’ve hired Ken, who is one of the most patient and detail-oriented people I know, to work on improving Tessel’s JS and Node compatibility. We’ve also hired an external contractor to work on some of the finer points of JS compatibility like the unicode implementation.

    Unanswered Questions

    We’re really excited about our new direction but we still have a few questions to answer:

    • Who are our customers? Tessel’s customers are usually web developers interested in hardware. But now that we’re starting to prototype tools for the wider user group of product developers, how do we market our product and who do we approach about user research? We also need to gather more information about how much of our current customer base is interested building scalable devices and how many are building one-off solutions.
    • Is this user group big enough and growing fast enough to be sustainable? Tessel itself hasn’t yet answered the question of how big the group of hardware-interested web-developers really is and it’s unlikely that traditional product developers will use our system until it’s more proven.
    • How do we go about automating the “human” parts of hardware development? The deals with manufacturers and working with suppliers, smoothing out issues with contract manufacturers, and debugging issues with field application engineers all currently require face to face interactions.

    Going Forward

    We’re continuing to dish out more Node and JavaScript compatibility for Tessel and make WiFi more robust. We’re pushing forward with enabling more programming languages on Tessel, enabling more microcontrollers and microprocessors to take advantage our runtime, and looking into more diverse wireless hardware. We’ve released the Project Portal to share Tessel-based projects and we’re working on remote code deployment. More and more Node Modules are starting to work out of the box, like Twilio and MQTT.

    We’ve still got a lot of work to do before we start making the hardware development experience we’ve been dreaming up. In the past year we’ve learned a ton about what it means to build a company but we need to start talking to users to get these new questions answered. If you have experience or suggestions you’d like to share, please email me at jon@technical.io. I’d love to hear it.

    We also have open, full-time positions that we’re hiring for, including web developers, HR/recruiting, business development, and firmware engineers. If you’d like to contribute to our vision of reimagining hardware development, don’t hesitate to reach out!

    #tessel #motivation #startup #vision #reinvigorate #hardware #scaling #node #prototyping

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013