Dion Almaer

Software, Development, Products

Platform

Developer Productivity Matters

I have been fighting for investment and focus on developer productivity for a large part of my career. Platforms often focus on the user side more, and think that the focus should be on solely economic opportunity. Understandably, if you can’t persuade a business that their effort will result in profit, you won’t get resources applied.

I can’t tell you how often I have heard a version of the following:

“Hell. Developers rushed to learn Objective-C to build iOS apps!”

— Bizness Guy

The gold rush was real on getting apps available for the exploding usage on the iPhone, but while Objective-C looks weird to many from the {curly brace generation} it is actually an elegant language (sure, it has quirks, but don’t we all!). This flippant repost also ignores the quality in the UIKit foundations, and the quality of tooling.

Pete’s right!

Economics of a platform are important, and are an input into how many developers can be hired, but there are clear reasons that it is important to focus on developer productivity if you work on a platform. I contend that the vast majority of platforms are under invested in their support of developers, and haven’t reached the point of limited returns. Why?

Time is precious

A developer has a set time budget that is fixed. There are priorities coming at them from all sides. The “business” wants features, features, features. The platform is forcing deprecations, and requirements for performance, accessibility, and security.

Time well spent

If we can take away any time that is wasteful, we can optimize the time well spent of a developer. This allows for more productive output per time slot.

Another important characteristic of time well spent is that we aren’t JUST talking about pure optimization of effort. Developers want to do a good job, and are quite willing to spend time that results in higher quality experiences. We want to do a good job, and have experienced getting into the flow state to build something great. The notion that “developers are lazy” is often misinterpreted. We just don’t want to waste time, just like humans hate any form of bureaucracy that feels wasteful.

Frustration is the productivity killer

If you are frustrated, time gets exponentially eaten up. Developers are engaging in a creative pursuit, and paper cuts slow down your flow, and get you in a frame of mind that is destructive. When you are enjoying yourself, your energy levels won’t deplete in the same way as if frustrated. This is why it is vital that you track developer needs and frustrations and actively get rid of them.

If the platform is hard to use, and the tooling isn’t delightful, and the documentation sucks, well then the effect on time isn’t a set amount, but is rather a multiplier. You have the power to influence a multiplier. This is a big deal. Also, if you are particularly bad, that multiplier can go as low as zero, where the developer flips the table and does something else 🙂

Developers don’t scale linearly

While the economics of a platform may allow for hiring more developers, we all know that this doesn’t scale cleanly. As a team grows, you get increased communication costs, and it takes a very special team to be able to scale. Cut out the need and allow teams to be as small as possible, and to allow a team to be able to work in parallel as best as they can.

Don’t cop out on productivity

Don’t fall for it. Don’t think that you can get away without focusing on developers and doing everything you can to keep them productive. I remember someone who told me “The business doesn’t care about developer smiles” as though I was a hippy solely looking to care about our developers (which isn’t a bad thing!). Building trust is important. Having developers who love working on your platform is valuable. But beyond that, you want the flywheel from developers to be going as fast as possible. You want them putting their effort into quality new features. You want them fresh enough to want to put effort into areas that you care about in the commons of your ecosystem (performance, privacy, security, etc).

You should be doing everything you can to maximize time well spent, and taking on as many hard problems as you can, so your ecosystem doesn’t have to.

So, yes, developer productivity matters.

Ecosystem Engineering

Leave a Comment

“An ecosystem engineer is any organism that creates, significantly modifies, maintains or destroys a habitat”

— Wikipedia

When you are working on platforms, you have the needs of the producers, consumers, and the market itself. As the market, or platform owner, your job is to make sure that the ecosystem as a whole is healthy.

One key is to not get too greedy at the platform layer, as Bill Gates put it:

“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”

This is somewhat common sense, but why do we often do such a poor job of taking care of our ecosystems?

One reason is that it is a hard, complex slog. When you are building something new you have a lovely green field and pivoting doesn’t have the number of side effects. You don’t have as many dependencies to manage, so you can run fast and break things. You have built a lean product team with top notch engineers who are cranking through their sprints like Usain Bolt.

Then something happens. The success of the work slowly changes the game, and before you know it you may be in a situation where the team members don’t really know it has changed! The incentive structures in the company may have been setup to reward the wrong things.

For example, as an engineer, the way to get promoted is to tackle harder and more complex problems, delivering fantastic solutions, in record and reliable time. You level up by showing how your craft has improved. This may be utterly at odds with the needs of the day.

Let’s look at a real world example. The Web is too slow and this causes a major drag to the ecosystem health, resulting in the current epidemic. If you are an engineer on a browser team, you will be working on more and more complex technical solutions to either:

  • Taking the existing content, speed it up in the browser. Incredible work has been done here, and it gets harder and harder (and more complex). Compare older browsers and how they blitted pixels to the screen vs. the complex GPU architecture that is in there now.
  • Build new standards and implementations that have faster paths. This is geological time, and a ton of work too…… and the solution isn’t enough, you need adoption.

If your core metrics are based on browser metrics, these are the paths you will take. However, if your core metrics are around the speed of the Web at large, which includes other browsers, then your point of view may change. Your investigation occurs at another layer and you may end up with totally different conclusions.

For example, WordPress is a huge percentage of the Web, including new content. This may have you conclude that helping make WordPress faster (better AMP support, service workers, etc etc) will actually generate a truly massive impact on the perceived performance of the Web at large, and it may also cause a competitive push with other CMSes. We see this happen again and again. For example, Flipkart being the “Google Maps of PWA” drove a lot of mindshare in India on investing in performance, especially from the eCommerce vertical. But this work is far from sexy. Many engineers would rather NIH yet another amazing CMS versus go in and make WordPress better.

Engineering teams are naturally working on the next feature / version of the platform. Take something like iOS or Android. Their yearly drumbeat is intense. I get to see this first hand by witnessing the mammoth effort that the Android team takes on. As we tick to the N+1 version, it is natural to focus on solutions there, but the ecosystem lags behind.

This is why work such as the Android Support Library came from Chris Banes, an engineer in Android DevRel. If you are talking to developers everyday, you are living in the real world constraints of today.

It is critical that we line up the outcomes at the ecosystem level, allowing you to really wrestle with the problems that you face at scale. It is important to look at all the tools at your disposal to enact the painful, necessary change. You need to think through all of the carrots and sticks. This kind of engineering effort deals with much outside of the scope of code. Psychology, and economics, can be front and center.

This is when other functions come in. Is the full go to market team in line with the same metrics? E.g. BD, Marketing, Sales? When everything is aligned magic happens, however often I see this break down due to us wanting to break down the problem into small chunks. If we aren’t tying everything together we end up with small product teams that are focused on their product, versus the ecosystem. The goals revolve around adoption. Everyone is pushing their shiny thing.

As I continue to see this pattern, I keep realizing that we need more ecosystem engineering, and we need to change the incentives to truly allow “Product Excellence”.

NOTE: There are some teams that I have seen that go above and beyond here. One great example here is Rick Byers and his team, and their maniacal dedication to bring predictability to the platform.

Ecosystems vs. Platforms

Leave a Comment

I have enjoyed platforms, but I have loved ecosystems. As I was thinking about becoming a renoogler I was thinking about the Web and what made it special, and that lead to this tweet:


There are features I like (e.g. URLs) and parts of the developer experience that I enjoy (as well as parts that I do not!) but it is the core emergent properties that I love.

There is something special, albeit messy, about the Web ecosystem. One definition is:

“An ecosystem is a community of living organisms in conjunction with the nonliving components of their environment (things like air, water and mineral soil), interacting as a system.”

The Web is much more distributed in its power than many other platforms. We often think in hierarchies and assume that top down approaches make the most sense, but that isn’t what we see in our most successful systems: nature, or our bodies / brain.

Most people still think of our brain as the CPU of the body. It’s the CEO! It calls all of the shots! In actuality we keep learning that the brain is only a piece of the overall system. Our gut and nervous systems act as “brains” in some regards, and in general systems take care of a lot autonomously. Inside the brain itself it also gets murky. We create an ego, a notion of self, to make sure that we keep ourselves safe, alive, and ready to procreate, but what is that self? We have seen fascinating situations. For example, in patients that have had a corpus callosum severed we can see that both “sides of the brain” can actually act quite differently. Seeing someone answer verbally one way and write a different answer is quite… freaky.

In a natural ecosystem there isn’t a CEO tree in the middle of the forest calling the shots. “Ok lads, it feels like winter is coming so time to get rid of these leaves!”

Embracing these systems isn’t easy. I find myself thinking about the global financial system, quickly realize that there isn’t some guru out there who groks the entire system, and I freak out. The Fed doesn’t have all of the answers. It’s just too complex of a beast, but maybe that is OK.

There are still players who have a strong pull on the Web ecosystem of course. Google, Apple, Microsoft, Mozilla, Opera, W3C, etc are key to the evolution of the system. The developers that build on top of the core platform also add a ton of value and often enable the developer experience that we have today (that the core Web doesn’t give you out of the box). I know that it can be painful, not having someone come down from the ivory tower to tell you how to do something. I would sometimes envy the .NET folks when I was in the Java world. There was a new Web framework every five minutes, but with Microsoft you could just eat your ASP.NET. However, I was never tempted to .NET, even though I thought C# was superior to Java at the time. The Java ecosystem was so different.

What about the platform?

“A computing platform is, in the most general sense, whatever pre-existing environment a piece of computer software or code object is designed to run within, obeying its constraints, and making use of its facilities.”

You run within, or on top of, the platform. It gives you the constraints. You don’t have other, different and maybe competing platforms where you can easily run on top of (unless you go for cross platform tools, but even then you need to grok the different platforms).

The Web platform is shared. It is standardized, and although the implementations are never the same, they are getting more closely aligned rather than further apart.

So many of the core Web engines are open source, or are starting to open source now. Vendors are working closer than ever. Who would have thought Microsoft would be announcing an open source JavaScript runtime at JSConf?

It turns out that the threat of the app platforms are bringing together the protectors (and benefactors for sure) of the Web.

One of the reasons I was so excited to head back to Google was the fact that ecosystems are built into its DNA. I can’t wait to be part of the great ecosystems that are out there, and to give developers the partnership they need.

The right thing to do, is the right thing to do.