Topic 4 Posts

Software Economics

The invisible skill at the heart of every technologist

There’s a skill that’s core to success at all levels of software development, but it hides like dark matter: inferred, rather than observed, lurking beyond description and discussion. On a gut level, we know it’s necessary to the work, but we don’t often know how to teach it. You’ve either got it or you don’t in the perception of the average workplace.

Let’s call this skill investigative reasoning. Or, more simply: “working the problem,” as Apollo legend Gene Kranz might frame it.

(Let me know if MIT press has a $70 textbook explaining this, situating it in computing or engineering, and giving it a name.)

This pile of skills manifests as a reflex to make sense of an issue or failure, locate its causes, and design a fix. Without these abilities, you’ll be helpless in the stew of complex abstractions that define modern computing.

Consider a common software development workflow:

  • You write some code
  • It’s compiled, bundled, or otherwise transformed
  • The transformed code is transferred to a host device
  • The host runs the code

Failures can emerge at or after any of these steps. The code may have errors which prevent compilation. The code may have errors despite compiling fine, and they manifest only at runtime, during certain circumstances. There may be a failure in the systems that package and transfer the code, preventing it from running.

The experienced practitioner understands their job is to analyze the problem, develop a hypothesis for its source within the many layers of technology they’re using, and validate the hypothesis by checking logs, adding print statements, starting an interactive debugging session, or using other means of peering inside of the machine. Working the problem may require research: finding online discussions of similar issues, or consulting documentation.

But core to this activity for both the novice and the expert is a simple conviction: problems can be understood and investigation can yield solutions.

At any level, hobbyist to advanced professional, confidence in this premise is the indispensable requirement. Without the confidence to work a problem, it’s unlikely anyone can make progress in building and integrating technical systems.

Domain experience helps to work a problem. Every class of system, from microcontrollers to native applications to web apps, has its own set of quirks, its own unique abstractions and design decisions where trouble may sneak in. But working the problem is a skill that transcends domains. Fixing a broken software development toolchain can prepare you for troubleshooting the boiler in your basement.

The paranoia in hiring for software roles, I’m certain, is rooted in the fear that the organization will hire someone who is unable to work a problem, outsourcing their investigative reasoning tasks to others, depleting productivity per unit of headcount budget.

Working the problem is also a feature of seniority. Translating business requirements into software development tasks is an expression of this skill, as is understanding how technical tradeoffs (debt) in existing systems will impact the needs of new features. The more senior a practitioner is, the more likely they are to feel a sense of confidence working a problem no matter how many layers stack up—even when those layers are “non-technical,” derived from business or customer needs.

We laugh at the fixation on languages or frameworks in job postings, but even the most thoughtful organizations struggle to identify this set of activities as a job requirement, much less map their outcomes within the team’s problem space.

Not every person is the ideal practitioner to work a given problem. The startup costs in research, learning new tools, or picking up domain-specific expertise, may outstrip any return on investment. Still, I have to think that applying a more conscious growth mindset around this would give our industry better results in recruiting, professional development and retention than we have today.

How can we elevate our understanding of these skills? How can we instill the confidence needed to work a given problem? How can we better train people to be able investigators?

I think there’s a lot of missed opportunity here.

Developer experience: the basics

Periodically, tech Twitter swells with a discourse I find to be weirdly unproductive: people arguing about developer experience. Does it even exist? Does it matter?

I’m not going to recap the various head-scratchers in detail. But I do want to talk about what developer experience is, why companies invest in it, and what we all get for their trouble.

Spoilers: it's a problem of labor and software economics. A positive developer experience amplifies the return of effort invested building new software products.

The experience of getting things done

Put simply, developer experience is the sum of events that exist between identifying a requirement for a piece of software, and delivering code that satisfies it. Broadly, these events may be practical, emotional or social in nature.

Examples:

  • Referencing documentation to plan an integration of a third party service
  • Trying to install tools or libraries necessary to develop against a particular software framework
  • Getting frustrated because of an unfamiliar or undocumented design pattern
  • Successfully receiving help in a support forum when you get stuck

The practice of developer experience, of being deliberate in its design, is to identify the places of greatest leverage for clearing paths and relieving burdens. The objective is to improve adoption of a technology by making it easier to accomplish personal and business goals with it.

Developer tools: pickaxes in a gold rush

Selling developer tools is a straightforward business strategy. Rather than the risky bet of serving a broad consumer or cultural need, you can build technology that helps anyone who is building software be more successful.

Instead of trying to sell to hundreds of millions of users, you sell to a comparatively smaller handful of companies, typically by hooking their individual developers. If one of these customers succeeds, you succeed along with them, scaling your billings according to the growth of their business.

It sounds great, but there’s always a catch. In this case, your customers become a handful of technologists with a broad spectrum of experience levels and highly specialized needs. Your business success then rests upon a premise that’s easy to explain but harder to execute: making people more prosperous and effective because of your tools.

Leverage within the developer experience domain

How can you make people more successful and effective in accomplishing their goals? If we think of developer experience as the sum of all events between defining requirements and delivering them, we can identify some broadly recurring points of leverage.

Ergonomics and abstractions

Where the fingertips meet the keys, how does it feel to work with your tools? Does integration require painful, recurring boilerplate code, or can developers easily drop in your tools to solve a problem and keep moving to their unique implementation?

Is it easy to debug and inspect the state of your tools at runtime? When errors are thrown by your tools, is log output clear and descriptive, allowing further investigation and social troubleshooting on forums or Stack Overflow?

What is the everyday texture of life with your tool?

Tools that feel good to use obviously earn more loyalty, enthusiasm and word of mouth than tools that grate and frustrate.

Documentation, reference and education

How do people learn to use your tool? Do you provide clear documentation? Recipes? Tutorials?

What references exist for troubleshooting, debugging and discovery of features within your tool?

Thorough reference material makes it easier for developers to get the most out of everything you’ve built.

Community and ecosystem

Is there an active community experimenting and sharing their experiences with your tool? Is there a reliable, active, healthy venue where someone who is running into trouble can get help?

Is an eager community filling in gaps with their own tutorials, plugins, libraries and ergonomic improvements?

It’s easier to roll the dice on a new tool when you know that, should you need help, you’ll find a community that has your back.

Developer experience: the business cases

From these levers, we can identify the business cases for developer experience. In the context of the adopters of developer tools—whether individuals or teams—the question is whether a tool enhances their ability to be successful.

In a software production context, developer labor budget is among the costliest resources a business has to manage. Any tool that allows a business to get more for that budget is creating serious impact.

For purveyors of developer tools, the business case becomes clear as well. Success depends on adoption. You can improve adoption by addressing points of friction in existing developer workflows, and by making your tool’s experience more positive and productive than frustrating.

This doesn’t have to be hard

When we’re talking about developer experience, we’re talking about real things:

  • How people feel when using tools and making software
  • How effective they are in meeting their goals
  • How these factors converge into amplified productivity versus wasted effort
  • What leverage exists in your strategy to shift that balance more and more toward success for individual practitioners and businesses that might pay for your service

Developer experience is a process of shifting the economics of building software to be more favorable for every dollar or hour invested. There's a lot going on there, but conceptually, this doesn't have to be that hard.

Wordle: A factional skirmish for the soul of technology

So check out today's Twitter beef.

You know all those emoji squares that have been popping up everywhere? That's Wordle. It's a bracingly earnest word puzzle web app deliberately built to a non-commercial ethos.

Wordle is a darling of the press because of its artisanal, small-batch sensibility. No compulsion loop—you get one puzzle per day. The score-sharing tweets are informational, instead of promotional. The tweet isn't about getting your friends into a conversion funnel.

It's about showing off your adventure and prowess.

Cue the stormclouds: a guy came in, saw the cultural fervor for this, and decided to build a paid, native application, using the same name and design. Taking people for $30 a year if they keep the subscription, this Pirate Wordle started printing money.

And its developer decided to tell Twitter about it, making him the day's Main Character:

Zack Shakked gushes about the game he cloned.

A schism in tech

The Wordle beef happens at a particular cultural fault line. Information technology has politics of all kinds, but one of the most strident is described on a spectrum:

Technology used for:

joy and wonder...sacks of money

Software automation is incredible. It offers leverage unlike anything we have ever seen. You can be worth billions of dollars because you build something that solves broad-scale problems for just $0.003 a user.

Sofware is all margin.

Which attracts the money fetishist.

Money fetishist?

Money's only something you need in case you don't die tomorrow.

Martin Sheen said this in Wallstreet, and it fucked me up for life. You can't unsee it.

This is absolutely an age where having money has become synonymous with safety and security. I can't fault anyone for trying to be okay, nor being strategic about it.

But some of us are building an entire identity around being the sort of person who has money, can get money, is the ultimate money chessmaster.

They'll go through any trial proudly for access to a capitalism lottery ticket.

So, for the money fetishist, software is an irresistable lure. Software is a lottery ticket dispenser. There are scratcher tickets, like building indie software. Those are occasionally gushers of a win.

But the scale goes all the way up to lottery tickets in the shape of a term sheet for massive investment to build a company. Assemble the right team, seize the right market, and you're a billionaire.

For this group, joy in computing is not always central to their goals. Mostly their participation in information technology is a cold calculation: "how many disposable robots can we build to seize a market?"

Computing's true believers

To the other end of the spectrum, this posture is off-putting, even revolting. For better or worse, the opposing faction truly believes in the power and wonder of computing, for its own sake. Money is a second order concern to pursuing the magic of making sand have dreams.

@computerfact: computers think using etchings in poisoned sand and measure time using vibrating crystals so if you were looking for magic you found it

It wasn't always obvious—either individually or societally—that the computer was a money printer. For some folks, the computer was simple fascination. An all new frontier, defined by different rules than our everyday existence.

Everything that makes computers good at money also makes them interesting.

For many, huge chunks of a lifetime have been dedicated to exploring the power of a digital realm. Building up skills, knowledge and imagination for a playing field that's not always intuitive, but so often rewarding as you develop mastery.

This is also a path to lottery tickets. Sometimes exploring the frontier leads you to a gold mine. But on this side of the spectrum, you've got people eager to explore computing as a creative endeavor first, grabbing what money they can in case they don't die tomorrow.

The beef

Wordle exists at the maximal edge of this non-commercial ethos. It's earnest in its humane approach. Instead of an engagement treadmill, Wordle is a limited, daily treat. Rather than promoting Wordle, the tweets for announcing a score simply describe the player's adventure for the day as a score with some emoji. No URL.

Wordle score panel: 207 5/6

In the context of Wordle's cultural froth—all these articles, all these score tweets—developer Zach Shakked saw an opportunity. To take Wordle's name, concept, and design, then strap a yearly subscription price to do it. Where the original Wordle was written for the web, this clone was built as a native iOS app, the better to capitalize on Apple's built in payment system.

My bias here: I think that move is tacky as hell, and quite possibly legally actionable. You can draw your own conclusions.

Quite a few more took exception to this approach. Kottke sums up the prosecution's case succinctly:

This person stole Wordle (a game @powerlanguish invented), put it on the App Store, and is now crowing about how rich it's gonna make him. 🤬

What this beef can show us is a fault line in the culture of those who participate in technology. Some for fun, others for profit. This is a long-brewing conflict, and you can find the seeds of it going back generations.

This Wordle beef gives you a model for this conflict that's small and fast enough to dissect as it happens.

But it's not the only beef you'll find in Wordle town. Did you know what those scores are like for screen readers?

Epic's ambitious plan for Unreal Engine and content-as-a-service

Fascinating twitter thread by game professional Mike Bithell about the strategy Unreal is telegraphing with their recent Matrix Awakens tech demo:

Epic is attempting to flip the economics of game production towards film production.
In games, we build everything, so (and this is over simplification) game assets are a fixed cost. If I need 100 things, I need to pay for the production of one thing a hundred times. Efficiencies come in, but we're still building stuff from scratch.
An open world game? Only possible if you're a mega AAA company, or you wanna stylize to the point of affordability. Movies don't build a city, they find one to shoot in. They buy props and costumes. They hire actors rather than making westoworld style puppets.
Asset stores brought some of this prop shop and central casting mentality to games, but the problem is aesthetic consistency. If you buy 10 characters off the unity store and throw em in a game together, unless you did so very tastefully, it's gonna look shit.

With Epic offering a fully coherent city backdrop, including efficient rendering technology and consistent design across characters and architectures, Mike argues, it becomes cheaper than ever for game devs to tell stories in realistic settings. This introduces new tradeoffs:

But it also increases the quality bar and expense of doing anything that's not on the shelf. Alien characters? Metahuman with some forehead bumps added... 6 limbs is expensive and out of scope. Guns? Take a prop gun and stick something on it. 90s film solutions.

I think it's interesting to see Epic touting this just a year after Cyberpunk 2077, an ambitious platform play that nearly tanked its developer, CDPR.

Sure, Cyberpunk is a game. It's also an elaborate canvas of characters, settings, and content that they can use to sell a series of stories. Night City is enormous and immersive, and the initial story they shipped barely scratched the surface of all they built there. I suspect we'll see plenty of paid DLC over the next few years leveraging that investment.

CDPR was hoisting an enormous open world, full of systems that could be reused. The complexity of pulling something like this off is formidable, and in Cyberpunk's case, led to a disappointing initial release full of technical issues, especially for players on older consoles.

Epic, decades deep into the game engine business, understands most teams don't have the capital or risk appetite to undertake that level of investment, but sees a similar opportunity to build that kind of canvas and rent it out.

As Bithell says:

Movies don't build a city, they find one to shoot in. They buy props and costumes. They hire actors rather than making westworld style puppets.

The software economics of games continue to evolve.