A common misstep I observe in both startups and large companies is the misidentification of their true customer. Any development methodology that relies on customer feedback to iterate on features will live or die based on how quickly they can deliver features requested by entities that are paying their bills. Thus it’s common to conclude that people that give you money are your customers. Simply stated this is a false assumption and it can punish your business.
A well rounded test suite gives you confidence that your code is stable and can handle a variety of use cases. It can also help discover issues before your customers do. End to end testing comes under fire a bit for being more trouble than it’s worth. Many of the issues are a side effect of maintenance around front-end testing. Changing a label or a class on an item on the view can cause a failure in your test suite. API end to end testing can prove pretty valuable however and since it’s decoupled from the view the focus is on testing accurate response payloads, HTTP response codes, Authenticated responses, and other API contracts. It’s fairly simple to set up, configurable, and you can even add the test suite as a job to your Jenkins build. I bet you can could even get testing set up quicker than you can finish reading this blog post. So let’s get started.
I’ve played or watched basketball pretty much my entire life. At 5 I would go in the back yard and dribble a ball with my right hand up and down the stairs and then do it with my left. I would also stay up late watching Chick Hearn tell me to put the butter back in the fridge because Kareem and Magic had this one in the bag. Recently, there’s been a shift in the game from teams using a huge center like Shaq, Wilt, or Kareem to teams playing what’s known as “small ball” or having a bunch of smaller, quicker players that can hit long range shots with great accuracy. Why would coaches and teams change the formula from what’s been successful for decades to a more risky, new style of play? I found this question really interesting. I hate to be hacky but they are truly ‘disrupting’ the game much like startups try and disrupt established markets. I decided to dig and look for other similarities between this new style of play and its correlation to startup mantras.
A couple months ago after dozens of flights back and forth to the Valley, and meetings, and due diligence, and meetings, and due diligence, and meetings (did I say meetings?), we got acquired by Qualcomm. We were all super excited. I think a lot of the excitement came from the recognition that someone else thought we were making something awesome in the education space. Someone wanted what we were cooking. After writing education based software for a long time it was gratifying to know that your work was deemed acquirable. I remember being so lazer focused on my current work that I never really stepped back and saw all that we accomplished on a macro level. The acquisition actually forced me to step back and look at the forest not just the trees. We then assimilated into Qualcomm.
For a long time I’ve used new startup ideas as catalysts to learn