DevOps, Tesla, and The Machine That Makes The Machine
It was announced recently that Tesla surpassed Ford in market value. While some of that evaluation can be attributed to hype, that’s still real money that investors are pouring into a company that was born less than fifteen years ago. How did this startup surpass the value of a company with 100 years of growth and market penetration?
Elon Musk is driven by a radical vision, but it’s his ability to execute that astounds me. There is a core competency Tesla displays that can be applied to nearly any business that produces goods, a specific way of focusing on the process that is a subtle, yet impactful, way of working. The benefits of this idea go double for software development, which can rapidly implement it without hardware investment. Of course, Tesla is not the first company to use innovations in process as a competitive advantage. In fact, that’s how rival Ford got started.
A Brief History Of Manufacturing Methods
Henry Ford, more than 100 years ago, was also was driven by a radical concept: getting automobiles, heretofore a luxury of the rich, into the hands of the people.
“I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one.” — Henry Ford
Automobiles were labor-intensive to assemble, and no two were the same. Bespoke coachwork was the norm, as was crafted mechanical pieces. To battle costs, Henry Ford invented a little something called the assembly line. The importance of this cannot be overstated, the concept radically changed the world and allowed for even complex goods to become commodities. Prices for furniture, electrical appliances, and vehicles started to fall, allowing a better standard of living for even those without incredible means. Our modern world would not exist without mass production of goods, and mass production itself would not exist without the assembly line.
In the early years, the perceived way to increase output was to increase batch sizes and throughput. This caused the unfortunate side effect of also increasing waste and re-work, and limited the ability for variety. Lean manufacturing methods innovated by Toyota starting in the 1930’s flipped that model on its head: smaller batches, more variety, and increased quality were the goal, all without decreasing output. Several techniques in lean manufacturing for accomplishing this include keeping work-in-progress to a minimum, introducing self-monitoring manufacturing equipment, and focusing improvements on bottlenecks. These techniques also lend themselves nicely to software development. Read The Phoenix Project if you want an enlightening look into the crossover between lean manufacturing and software development. I would consider it required reading for anyone in software.
The Machine That Makes The Machine
This brings us to today. Even with the inclusion of increasing automation in manufacturing, the fundamentals still remain. Musk builds on all the work done by Ford and Toyota by suggesting that the process itself must be viewed as a product that needs to be constantly improved. Perhaps this is a subtle difference than our current state of things, but it is an important distinction to make.
“We realized that the true problem, the true difficulty, and where the greatest potential is – is building the machine that makes the machine. In other words, it’s building the factory. I’m really thinking of the factory like a product.” — Elon Musk
Like Henry Ford’s assembly line, this mentality has the power to radically change our world. Many current production methods are fast, but as an engineer at heart, Musk views manufacturing as something bound only by the laws of physics. To him, it’s not good enough to create a passable process and then focus on the product. We need to focus on the process and the results will come.
So what results are Musk hoping to accomplish?
“You might think that some of the most advanced car factories in the world are very good at making cars and they are maybe making a car every 25 seconds… That’s 0.2 meter per second or not much faster than a tortoise.”— Elon Musk
Elon, the man who has defied expectations time and again, expects to see that number climb to walking speed. He also expects that the volumetric density of factories could shift from around 2-3% of used available space to 20-30%. This a literal order of magnitude. The idea is to do more with less, to condense the size of the factory and improve the throughput, all without losing the ideas about allowing for variety of product and reduction of waste put forth by lean manufacturing.
Your Process Is A Product
If establishing a 10x improvement in Elon’s eyes seems doable in the manufacturing space, imagine what is possible in software development where the pace of progress is not restricted by the physics of motion. We are restricted by electrons, clock cycles, and network speeds, which are rarely the problem when figuring out what we should work on in our process. Usually it’s the squishy humans that become the bottleneck.
Treating your own process for software development as a product is a natural extension of DevOps and should likely be tackled after you have the fundamentals of DevOps folded into your process. Once you have the basics in place, you can start treating your process like a product:
- Version your process
- Keep a prioritized backlog
- Work in sprints
- Assign deliverables
- Measure results
- Do retros
- Get client (developer) feedback
- Assign a key stakeholder
- Allocate time to work on process
- Allocate a budget
- Document changes
- Allow for rollback if necessary
Often, improvements to the process are left to chance. Tell me if this sounds familiar: everyone knows there are gains to be made, but no one is quite sure where to start and who has time for it anyway what with the magnificent new feature due Friday. It’s a story echoed across many organizations. Rather than setting up meeting after meeting about process, maybe it’s time to treat it like a product.
I’m not advocating for stopping work altogether to do this. How do you know if you’ve improved your assembly line if nothing is moving through it? However, go in knowing the work will occasionally need to stop or slow as you fix a part of the process and then get it running again. Create a sprint for the process, which includes resources, a start and end date, user stories and tasks. User stories might look like “As a developer, I want to be able to publish to the developer site on every checkin,” or “As an end user, I want bugs I log to automatically appears in the backlog.” Once you get in the mentality, viewing the way you make software as an entity that can be measured and improved becomes second nature.
Don’t leave process improvement to chance. Take charge and treat it like a product.3