by on April 13, 2016
While Internet Companies shortened the release cycle, Software as a Service (SaaS) providers turned it into an art form. Thanks to agile development methodologies, it is now common to measure deployment cycles within weeks instead of months or years. However, making more deployments is not the point. The real issue is the need to continuously improve upon the code.
Putting feature updates aside, we must examine why we need to build a product then spend the rest of our time improving upon that product. My first inclination is that this is the wrong way to think about development. Afterall, the ketchup company does not continually update their product. They get it right first, then take it to market - not changing it for decades.
However, on further thought, these products enjoy much Research and Development (R&D) that goes unseen by the general public. Instead, software is different in that development and R&D coexist as part of the release. Each sprint has some R&D mixed in with the creation process. This makes software unique.
Automotive companies like Mercedes, spend millions on R&D in the form of Formula One racing. These teams compete where a hair width advantage means the difference between loss and victory. Their findings trickle up to the company where the engineers and designers implement the discoveries into their product.
A Formula One team faces tremendous risk. It takes around $120 million per year and a $47 million entry fee to have a race team. In addition, the governing body, Fédération Internationale du Sport Automobile (FISA), requires each team to own the intellectual rights of their chassis they enter. Thus each team must create and continual improve upon their vehicle and team processes to remain in the game. Therefore the Formula One team is a perfect model for both the software development team and startup enterprise.
The startup company looking to win is faced with even more similar obstacle as the Formula One team. For instance, the only Formula One team still around since the inaugural 1950 season is Ferrari. The reason is that the cost involved to maintain and race Formula One is great while the time it takes to create a winning team is long. Therefore most teams go bankrupt before being able to turn a profit. Sound familiar?
What is more interesting is the advent of the factory team. During the early years of Formula One, most teams were owned by car companies. They functioned as both marketing and R&D for the manufacturer. Then during the middle years of the sport, private teams appeared. However, the manufacturer team is making a comeback and private teams are being acquired.
Now we see the similarities, let's examine how it relates to software development. First, all Formula One teams must own the intellectual rights to their chassis. This means that teams must have an original car. While similarities exist between cars, there has to be something unique with each one. In addition, each car must continuously be improved upon to remain competitive.
This leads to first core reason for continuous deployment - to create and maintain a strategic advantage. As engineers, the strategic advantage is not always on the forefront. However, the only reason for improving software should be strategic advantage. Afterall, even bug fixes have strategic advantage.
For years the software we use has been plagued by a good enough mentality. A Company builds a SaaS product, works to improve upon it, then either goes bust or gets acquired. The result is the software is either placed with a more bureaucratic entity or relinquished to the open source community where it often becomes forgotten.
This introduces what I call the pioneer problem. For example, Auto Union, later to become Audi, invented the mid-engine race car in the 1930’s. However, this design was not successful in Formula One until 30 years later, after being perfected by others. This is seen in software too. Companies like MySpace, Yahoo, and others invent spaces only to get beaten later by others who perfect the idea.
Thus it seems that it is better to improve upon existing technology over inventing new ones. However, this is not without a caveat. There are game changer technologies that give such advantage that teams enjoy years of unprecedented success. A perfect illustration from Formula One occurred In 1962 when the Lotus team developed an aluminium-sheet monocoque chassis - changing the game forever.
As in Formula One, our game changers in software comes most from the simultaneous increase in both quality and speed of development. The reason is this allows the fastest to market and greatest opportunity to improve upon the design before any competitor can. That is, improving the development process is the main strategic advantage for a software team and the core reason for continuous deployment.