Tesla

Lately I’ve been reading up about Tesla Motors, the automotive company founded by PayPal Co-Founder, Elon Musk.

I’ve been thinking about the automotive industry over the last 12 months and I’m convinced it’s an antiquated industry. Being in the tech business I am fortunate enough to make it my job to learn as much as I can about the future of software, technology and the connected world. Every day I see software entrepreneurs and inventors progress in leaps and bounds however when I get into my car I feel like I’ve gone back in time. My car is not an old car. I bought it in 2008 and I have all the gizmo’s such as bluetooth, reverse sensors, GPS, hands free, voice activated dialing and so forth, however I still feel that my car is antiquated compared to my computer or iPad.

Given the advancements in the world of software and “the internet of things” I am blown away that only one car manufacturer has been able to use software to make the automotive experience significantly better. That company, of course is Tesla Motors.

What Tesla has done is nothing short of astonishing.

  1. They have built a car that is 100% electric (no fuel at all)
  2. They have build an ‘operating system’ that is used to control every facet of their vehicles from a touch screen
  3. They are rolling out charging stations across the US and Canada creating a huge barrier to entry

Every few years an incredible company is born that ends up changing our world. Microsoft and Netscape did this in the mid 90′s. Google did it in early 2000. Amazon did it to books and retail, and later AWS. RIM followed shortly after, then Apple came along and blew RIM out of the water.

Tesla is one of these transformative companies.

Not only are their cars electric, they are also controlled entirely by an API. The 17″ touch screen in the dashboard sends API commands to a computer within the vehicle that triggers events to ‘do stuff’. Unlike my car where I flick a mechanical switch and push a button to turn on the airconditioner, the Tesla has a touch screen. For example if you want to open the sunroof, you ‘drag’ the sunroof open on the touch screen and the roof begins to open above your head. The electric engine is cool, but so is the thinking that has gone into reinventing the car.

If I was the CEO of Mercedes-Benz (or Ford, or any other automotive company) I’d spend $50m on an ‘acqui-hire’ tomorrow to snap up a hot shot software team in Silicon Valley capable of creating an operating system which could be used to control their vehicles.

Within the next 5 years, every car should have a ‘Tesla” style 17 inch internet connected touch screen embedded in their dashboards. We should be able to download apps to install them in our cars, and all components should be controlled via an API. This will sell more cars than larger engines.

Click to enlarge this image of the Tesla dash:

Network effects

Tesla also has network effects. Tesla is currently installing charging stations across America and Canada to enable customers to ‘Super Charge’ or ‘quick charge’ their cars on busy routes across these countries. Tesla charging stations could well become the new ‘petrol station’ and once enough of these exist, it becomes very difficult for other car manufacturers to roll out their own versions of these proprietary charging systems. As Tesla’s technology improves and prices drop (which they will), consumers that want to save on gasoline (who doesn’t?) may be forced to buy Tesla cars as Tesla would have the most mature charging network of any car manufacturer. I can envisage a world where we are all eventually driving Tesla’s because its the only electric car manufacturer that has a pervasive network recharge stations. The result is a Tesla ‘eco-system’ which I’m confident has the potential to do what Apple did to mobile phones, to cars.

Silicon Valley

The innovation that has come out of Tesla could only have been executed by a Silicon Valley entreprenuer.

An Israel company named Better Place tried to invent the electric car. They did this in conjunction with Nissan however after billions of dollars of investment the venture has yet to amount to anything of significance. I’m not 100% sure why it has not worked out, however I suspect that one of their problems would have to do with their decision to partner with an existing automotive manufacturer. In order to innovate on the combustion engine you need original thinking. The engine was invented over 100 years ago and radical change requires someone who is able to challenge the status quo.

Unfortunately, Nissan was an incumbent trying to be something they are not. We’ve all seen this one before in that Sony did not have the foresight to create the iPod, and if they did, their brand did not have the cult status of Apple.

It took someone from the outside world of music, movies and cellular phones, to change the industry and Elon Musk is the guy that is doing this in automotive.

API

What Elon Musk is doing to the car is what Steve Jobs did to the phone. Jobs used ‘software’ to reinvent the phone. He built an operating system for the device (iOS), added some sensors, then opened up its capabilities via a set of APIs.

Here are two examples that show you how a Tesla vehicle can be controlled via the command line of a MacBook:

Tesla is an amazing company which is just getting started and I can’t wait to see where they are in 20 or 30 years time!

Technical Luck

When building products for the Internet, no-one builds ‘everything’ from scratch. Web services are almost always a mashup of existing technologies and third party services that come together to form a product. Entrepreneurs use API’s, SDK’s and hardware from a range of vendors to create their products. This might be as simple as using an existing open source software stack to launch a WordPress blog, hosted by Go Daddy. The end goal for the user is to create a blog, but they don’t want to be concerned with developing a platform to do this, or configuring servers. They just want to be able to write and publish their thoughts.

I often think about start-ups and the timing of their success with regard to the technical capabilities the preceded their services and whether or not their business could have existed 6, 12, or 24 months ago. The ability to leverage an existing technology and build something valuable on top of this, is what I refer to as ‘Technical Luck’.

A good example of this is Square. Square is a payments platform that is currently valued at $4bn. What would have happend if Apple did not allow for the headphone socket on the iPhone to work as a microphone? If this was the case, Square would not exist because they could not process payments via the Square card reader that plugs into this port. This tiny feature enabled Square to build a $4bn business.

Another example is Instagram. If Amazon Web Services did not exist, Instagram would never have been able to scale to meet demand with just 3 or 4 staff. It could have been a disaster.

There are services out there that let you leverage incredibly powerful and scalable features that make it possible for Entrepreneurs to move swiftly.

These examples of ‘technical luck’ make breakthrough products and services possible simply because of a some pre-existing features or services that can be leveraged in a few lines of code.

Going Agile

It’s been a while since my last post and I feel like I should have written a few more times since then however I’ve been pretty much flat out working with our team to prepare the finishing touches of BuyReply. We are going to be launching in two weeks and are putting the finishing touches on our product.

When we first started building BuyReply there were a few of us designing and developing and we weren’t all working from the same office. I wrote a 95 page functional spec and designed around 450 screens for desktop and mobile then worked with my developers to turn this into a product. We spent 3 months planning before we wrote our first line of code.

While we were developing to a functional spec it was relatively easy to know what everyone had to do, however we are now in a situation where most of the spec has been developed. We are working on tasks such as our deployment processes , continual integration configuration, testing processes and minor feature updates that will set the stage for our business moving forward.

It became clear in the last week that we needed a process that could be used to manage our team and ensure everyone is on task, productive and aware of what each team member is doing at any point in time.

The solution to this problem is to implement business processes that we adhere to with discipline on a daily basis.

After some research we’ve decided to start using an Agile development approach. Agile works by breaking work into a Roadmap, Projects, Sprints and Tasks as well as meetings called scrums, planning sessions & sprint reviews.

Agile components 

Roadmap - This represents our long term plans and includes high level goals that would extend over a 6-12 month period. It includes major product features. An example of this might be ‘building analytics functionality’ or ‘enabling 3rd party inventory integration’.

Projects - This represents short term goals that can be broken down into sprints. These are more clear requirements. Examples include:

  • Launching version 1.0
  • Building a web hooks module
  • Exposing our orders and customers API

Sprints - Sprints are the building blocks of Agile and should be 2-4 weeks in length. Projects are broken down into two week sprints that include tasks. Once a sprint starts we do not make changes to the requirements. The scrum master polices this.

Tasks - Tasks are work units that can be broken down into 1-16hr blocks that can be completed by a single person. Sprints are broken down into as series of smaller tasks. Examples might include:

User story: If I have multiple cards in my wallet I should be able to select the default card and if that card is not accepted by the merchant it should land me on a page where I can see a list of cards that the merchant accepts, and enter a new card.

  • Add a radio button that enables a user to select a default credit card in their wallet [3hrs - Adam]
  • Create a page that displays the credit card form [3hrs - Adam]
  • Test an debug this function [1 hr - Adam]
  • Acceptance test this function [1 hr - Dave]
  • Document this function & update marketing site copy to include this [0.5 day - Dave]
  • Update marketing site [2 hrs - Joanne]

Meetings

Scrums

Every morning we will get together at 9:00am in the meeting room for a scrum which lasts no more than 15 minutes. We do this standing up as that forces us not to relax and getting conversations that waste time.

Scrums occur away from our computers and each individual has to report on three questions every single morning:

  1. What did you do yesterday?
  2. What are you working on today?
  3. Have any roadblocks that have arisen that have cause the sprint to slow down, and what are they?

It is the role of the scrum master to remove roadblocks however this must happen outside of the scrum itself to ensure the scrum lasts no longer than 15 minutes.

In this meeting attendees are not reporting to the scrum master or product owner, they are taking responsibility for the tasks and committing to completing them.

There are three core roles of the scrum

  1. Product owner – this person represents the voice of the customer. They are responsible for representing the voice of the customer, defining user stories and what is going to be built. This person can also be a member of the development team. I am going to assume the position of scrum master as I have a clear vision of the direction of our product.
  2. Development team – Usually 3-7 developers working together. This team should be self organising and work together to get software built. The product owner (myself) can be a member of this team, which I am at this point in time.
  3. Scrum master  - This is a person who protects the development team from distractions and fends of external influences that might cause them to lose focus.

Sprint Planning

Sprint planning are 3-4 hour sessions where a 2 week sprint is planning and every task is broken down into a 1-16hr block. Work is never assigned to a person – you sign up for work of your own choosing based on what needs to be done.

Sprint Review 

This is a demo of the work done in the sprint. It is not a presentation. You need to show working software.

Documents

Product backlog

A backlog of functions and features that can be turned into a sprint. Think of this as a pile of sprints and we choose one, feed it to the team, get it done, then take the next one. We constantly pre-prioritize the product backlog.

Sprint backlog

This spreadsheet represents a list of new work the is still required, and the estimated hours require to complete this over a 5 day period.

Burndown chart

This chart represents a number of hours required over time and shows you how fast they are burnt down. It represents the velocity of work.

I’m looking forward to implementing this process at BuyReply and expect that we will be more productive moving forward because of it. We are weighing up whether to use TFS, Asana, Greenhopper or Trello to manage this process. Any feedback would be welcomed!

Enhanced by Zemanta

The programmable data center

One of the benefits of starting BuyReply is that I have been able to reconnect with technology. BuyReply is a software business whereas Lind Golf was a retail business that happened to be online. I don’t view eCommerce businesses as technology ventures. Selling product online is no different to selling product in a store, it’s just a different kind of shop front.

I’ve always enjoyed the technology and systems side of business more than product and trading and I’m glad that I now have a business where much of its success depends on this.

As we’ve built out BuyReply we’ve had to architect it in such a way that it can scale. One of the challenges of building a system that will generate much of its traffic from Television is that television can cause huge spikes. For example if a call-to-action is displayed on television to email or tweet an address, hundreds of thousands of requests could arrive at our servers in a matter of seconds or minutes. If an audience has 1m viewers watching a show like MasterChef, and a call-to-action was displayed that said ‘email desert to recipes@masterchef.com.au’ to get this desert recipe, there is a good chance that 20% or more of the audience would participate. Thats 200,000 inbound requests in a matter of seconds. In order to combat that we’ve designed an architecture that can scale.

As a startup mentor I try and persuade startups not to spend too much time worrying about scale until they have enough customers as building for scale is an engineering task in itself, however we’ve had to think about scale from day 1. Luckily Amazon Web Services exists.

What we’ve done is architected the application so that it can scale however our staging environment is hosted on a single server. I think it is very important to build your application for scalability early on so that you dont have to rebuild it later. You don’t have to host on scalable hardware at the beginning, however if your app cannot scale you might be in a bit of trouble down the road if you need to scale. We have a sophisticated queueing and queue processing architecture that is capable of running as a service on multiple instances. This means that we can distribute incoming requests across as many servers as we like should we need to.

This all sounds very complicated but in reality its not that complicated or expensive, thanks to the programmable data center.

We use Amazon Web Services to scale our service. Using AWS we can start with a small number of servers and add servers as we need them and you only pay for the servers you use when you use them. For example if  we are expecting a large amount of traffic and need 50 additional servers to handle load from a TV spike for 1 hour, we can boot up 50 servers in 2-3 minutes before the show starts, run them for the duration of the show and shut them down after. All of that that would only cost us $25.

As an old school MCSE, I am blown away by how incredibly powerful AWS is. What used to take weeks or months to configure and deploy can literally be deployed in a line of script.

Our entire BuyReply infrastructure which is made up of 10 servers, 3 security groups, two autoscaling groups, a load balancer and two mirrored database instances across two availability zones, can be deployed by pasting 10 lines of code into a terminal window. Within seconds the entire infrastructure is booting up and within 2-3 minutes its ready to accept traffic. All we need to do is flip the DNS to point to our load balancer and it starts working. The infrastructure is also highly available meaning that every aspect of the platform is mirrored and architected for fault tolerance and failover.

If we were to buy the hardware that runs BuyReply it cost well over $100,000 and require a team of sys ops to manage and deploy but thanks to AWS we have a programmable data center that is dirt cheap.

Many large web services run on AWS including Netflix, Drop Box and Heroku. AWS is what allowed Instagram to scale to billions of requests a day with just 3 engineers.

As a bit of a tech geek this whole AWS thing is a lot of fun.