Glenn Gillen

The following is a talk I gave at The Coders of 2021, an event hosted by Startup Victoria event.

When Thomas first asked me to talk on the topic I was wondering what incredible forecasting abilities I'd need to look that far ahead. And then I realised it's only 5 years away! While we're excited about the pace of innovation, the reality is that wide-spread adoption is much slower. And true industry changing innovation doesn't happen that regularly.

I'd say the last truly major shift we had was with mobile. Smart mobile devices are now ubiquitous, but looking back 5 years brings us to the release of the iPhone 4S.

How much has that space really changed since then?

My own experience and expertise lies primarily with developer facing tools. The products, services, languages, frameworks, and technical tools that help turn ideas into reality. So rather than prognosticate on what people will be working on, I'll stick closer to my experience and talk about how they'll be working on them. And to predict the future I'm going to look to the past, further back than the iPhone 4S, back to the last dot-com bubble.

To plot a trajectory.

And to take you on as rapid a tour of how we're moving increasingly to the ends of the hyper-generalisation—hyper-specialisation spectrum.

That's the cost, inflation adjusted, of a single Sun Microsystems Enterprise 4500 server during the first dot-com bubble. And they were the darlings of that bubble. Any well funded startup rushed out to fill the racks with them. You'd wait 6 weeks to have it delivered. If you hadn't already done so, you'd spend that time fitting out a server room. Connecting the utilities, adding the environmental controls, making sure it was cooled. Having an E1 line installed from Telsta. Running CAT5 everywhere. Getting all your Cisco routers setup. Then the server arrived and you'd spend another week racking and connecting, configuring the BIOS on it to talk to all your peripherals, compiling the base OS.

It all imploded, the bubble that is, and people (mostly) stopped burning money on servers and data centers. We bought cheaper hardware that more closely resembled our desktops. But more importantly we put them into co-located data centers.

That's the cost, per hour, to run a t2.nano server is Sydney. In 2006 Amazon introduced Amazon Web Services (AWS) to the world. No more building your own data center. No more provisioning your own fat pipes with a telco. No sourcing your own hardware to rack in a co-located data center. The hardware was already there. If something failed, someone was already replacing it.

Others have since entered the market, and as an industry a huge percentage of us have happily ceded the responsibility of getting a server connected to the internet to a 3rd party.

This isn't just a story about Moore's Law, and the ever decreasing costs of compute power. Nor is it a shift from capex to opex. This change has been transformative in both the way companies go to market and maintain operational agility.

We've given the responsibility of commodotised problems to specialists in the respective areas. The concentration of effort within a single problem domain, provisioning compute resources in the case of EC2, provides operational economies of scale to a company like Amazon that each of us individually would never be able to achieve. It also gives them a unique position to spot industry-wide patterns and address them efficiently. Again in a way that we, individually, would never have been able to do.

This isn't just a story of elastic compute power though. Look at the list of problems AWS alone has solved since 2006. Relational databases. Load balancers. CDNs. Block storage. Caching. Data warehouses. Full-text search. Streaming data processing. Monitoring. Log management. API management. Email. Message queueing.

There's an entire supply-chain involved in the delivery of an idea into the hands of a customer. And each step in that supply chain is becoming increasingly more specialised. More focussed. And managed by more efficient and more experienced people for a lower cost.

And so the job of a modern developer has become less about knowing how to spin up a postgres server, because you can have the most experienced team in the world manage it for you for $9/mo. It's more about being knowledgeable about what the parts are. And most importantly how to assemble them in the most innovative way.

We've already largely embraced this at an OS, language, and framework level. Rubygems, npm, pip, godep. Each language has its own package management system to make sharing code easier. Most developers aren't writing from scratch their own functions to process image uploads for the site, to resize it into the preferred size variations for icons/avatars/etc. There's even sites dedicated to helping you work out which particular library you should use, because there's probably dozens of them.

The next evolution, that is already well underway, is transitioning these standalone libraries to fully managed services. Because so many of these are iceberg problems, you only ever see the 10% that's obviously above the surface. But even resizing images isn't really just resizing images. You only need to hit a moderate level of scale and you need to start thinking about how and where you store them. Do you need to track revisions? You'll probably need to serve them via CDN. And then you need to reprocess all of them to support some new dimensions or filter because circular profile pictures aren't the rage any more and we've all moved to diamonds. Make it someone elses problem.

The vast majority of the problems you face today have been already solved, and productised, by someone else. What's left is to assemble them in an innovative way. And that's where we're heading in the next 5 years. Like turning individual Lego blocks into a fully-fledged Millenium Falcon, developers now need to have an incredibly general knowledge of the blocks available to them. Most of the job is just knowing how to use them.

At one extreme you have the hyper-specialised team maintaining a service like Heroku Postgres, their only job is to ensure the integrity of that database for you. At the other end of that spectrum you have the consumers of the service. With their hyper generalised knowledge. Knowing what blocks are available to them. What they do. And how they fit together.

But the specialisation spectrum becomes fractal. All that ceding of complexity and responsibility at the hyper-generalisation end buys back time, time to focus on what's important: what's the one problem you're solving? And so in actual fact it provides hyper-specialisation within the one problem domain your customers care about.

And so what we end up with is a concentration of focus and specialisation across the industry. The ability to stand on the shoulders of others. We're not just building apps by plugging a bunch of battle-hardened and externally maintained packages into our preferred framework. We're now starting to do the same with runtime and operational concerns. Leveraging the expertise and experience of dedicated teams to make our own products better.

And the abstractions are only increasing.

Building an Internet of Things platform? Surprise, Surprise! Amazon has you covered. Need to deploy changes to your fleet of embedded devices around the world? Take a look at Resin.io

Want to somehow add a blockchain network into the mix? Ethereum or IBM can get you started. Chain.com if you have a need to run it on prem.

Chat bots are all the rage. Don't build your own. You've got Pandorabots, ChatO.ps, Cog.

Why not add some AI or Machine Learning to your IoT blockchain enabled bot platform? Again AWS have an option for you. As do Microsoft. IBM have APIs to let you use Watson.

Never before in history have so many people been so connected, with so much access to information. Your job is to know as much as possible, about what is possible. And leverage it into solving problems in a unique and innovative way.

You are the builders. With so much Lego already at your disposal, the question is what's the future you want to build? Why haven't you started?