The Speed Read with Quentin Hardy: The modern fable of the developer and the tortoise

In 500 B.C., the Greek philosopher Zeno came up with a good way to think about modern software. In his famous paradox, Achilles and a tortoise agree to a race where Achilles would have to reach where the tortoise started. No matter how fast Achilles ran, the tortoise had a head start, so he could never catch up. The goal keeps moving, and Achilles never really reaches the animal.

Welcome to this month’s Speed Read, the “Those Greeks Were on to Something” edition. 

Zeno could have been talking about software—always advancing, never finishing, racing to meet change—but there are some key differences. Unlike the tortoise, market needs and appetites accelerate pretty quickly when developers speed up their pace. And, unlike Achilles, developers see this unending chase as an opportunity to change how their teams work, creating new tools and organizational methods to respond better. It’s never changed as much as it’s about to—with challenging and wonderful implications.

In the early history of software manufacturing, teams worked pretty much the way corporations processed customer surveys: Find out how your buyers feel about that mainframe or PC application, and make tweaks. The process sped up as the market grew, but it was manageable. 

The rise of the PC dramatically grew the independent developer market, creating and standardizing the waterfall model across the software industry with around 18-24 months per release. Patches sped this up to around three months, but the patch delivery system was so expensive that this was used primarily for bugs and not for new features. 

The rise of web-based development really sped things, since customer feedback (from reading cookie data to reading angry emails) was so much quicker—and because the software could all be updated in one place, rather than on hundreds of thousands of PCs. We got initiatives like A/B testing, making the browser a sensor to read customer tastes. We generated fixes to better approximate what the market wants. 

Faster tortoise, closer Greek hero, and on and on. Tortoises all the way out, so to speak.

At every advance, acceleration has had a notable effect on ways we organize programing, moving from the sequential waterfall style to spiral, to agile. With cloud, there is no benchmark upgrade cycle, there’s just lower cost and faster processing, depending on when companies want to change their offerings. That appears to change how people work.

Computation has gone from scarce to abundant, bringing about a bigger market that is moving faster. To keep up, the development process has to transform from the two year waterfall release schedule to the daily agile method.

To meet user demands, Google’s agile model changes were built on deep-in-the-weeds computer science problems—dependencies, pipelines, automated tests, and of course, containers. Those methodologies, along with creative innovations like open source—increase the crowd, speed the development—have taken us to the world today, with empowered devices, and cloud systems capable of analyzing and responding globally to changing needs. There are a lot of curved graphs involved here, and all the curves are going up and to the right at the same time.

Now that we are fast and scaling to billions of people, what’s the next step? 

Perhaps it is getting one of the toughest issues in tech right: Human empathy. Having the increased ability to read and respond to customer interactions requires developers to deeply understand their specific industry domain, their company’s own culture, and their relationship to their customers. IT departments will need to play a key role in early product creation, helping understand what data in a buyer’s interaction should be collected.

The faster the cycle of reading, changing, and deploying software accelerates, the more development and operations will need to become partners in each other’s processes. The goal should be to create the digital equivalent of Toyota’s vaunted total quality management system—a coherent group focused on overall tasks, with a consequent higher rate of productivity and a lower rate of failure.

Cloud providers like Google have greater responsibilities in customer understanding too. This extends to areas like our Customer Relationship Engineers, or CREs—the highly trained Google Cloud experts who architect large-scale projects with larger customers. It is also incumbent on cloud providers to build into our products and tools greater approachability, and sustained, consistent experiences.

As always, we’ll never get there, but we’re closing in.