Building A Fast Track For Software Development
I left Google 3 months ago after almost ten years there. I am now building on a fast track for software development teams. Today I will explain why this is important for me.
Data and software development spin Google’s revenue engine.
Google is extraordinary. With so many smart people trying to change the world, they create cool things every day.
At a high level, Google is a giant center for data processing and software development. You take massive amounts of data, put that in the world’s most scalable computing infrastructure, then ask brilliant people to do something interesting with it. Sometimes their work creates revenue (e.g., optimize ads). Sometimes it just generates more data (e.g., a new product that people use every day, like Gmail, Google Maps, and Android). Either way, it is a virtuous cycle:
software development + data => data + $$
Then you can use $$ to hire software developers and start again.
Every business is a software business
It is not just Google. More traditional companies are growing their software development teams because they agree with what Marc Andreessen wrote in 2011:
“My own theory is that we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy.”
The traditional companies going through the digital transformation are ranked by the market based on how fast their developers can transform ideas into products and create value for their customers.
When you add to that the competitive dynamics of the connected economy, you see why every company out there is scrambling to hire more developers and help them be more productive.
According to the U.S. Bureau of Labor Statistics, companies are projected to add close to 30k software development jobs per year for the next 10 years or so.
Why adding software development is not enough?
What happens when you add more developers to a team?
When you double the number of developers, you do not get 2x faster software development. It is a well-understood phenomenon. There are many books about it. However, I am intimately familiar with two practical reasons: software monoliths and broken release processes.
Monoliths happen when software services evolve organically.
Curiously, the monolith is a sign of success: when a software project gives good returns, more developers are assigned to work on it with the goal of creating more and more value. So they all start contributing code to the same application.
Over time, problems start to appear. Builds take several minutes or even hours. Tests are very flaky. Software releases are fragile and can take a long time to ship to users.
Chasing my passion
I am passionate about cloud infrastructure and developer experience. Since leaving the Google bubble, I have been studying how other companies are dealing with the challenge of scaling their software development. Each case is different, but I have identified common challenges:
- teams are stuck with software monoliths, or with microservices ops hell
- the release process is broken
I think there’s a significant opportunity here: what would the world look like if every company could move faster and deliver valuable software every day?
I have built infrastructure at Google that helped teams launch and iterate faster. It turns out that other companies also want to move quickly. I think I can help.
So I am starting a project to help teams have a more nimble and graceful development process. Stay tuned for more.
Do the problems above seem familiar to you? Let’s connect on LinkedIn and chat.
Stay up to date with the
lastest news from Yourbase.io
Other Articles You Might Like
Four years ago, my family and I moved from Zurich to Seattle. I grew up in Brazil and had the privilege to live in...read more
What are the benefits of microservices and why are they becoming so popular with large brands like Netflix? The main...read more
GitHub survived a DDoS attack of 1.35 TB/s. How? They paid someone else to figure it out, as they should. If you leave...read more