By Jason Lowenthal July 27, 2016

MoneyCode: Value

As a very brief reintroduction to the MoneyCode series, here’s the essence boiled down to a single question:

How do software engineers deliver more quality value faster?

The first article of the series concentrates on delivery. Specifically, it declares that the only thing that matters is getting software into production. Without it going to production, there’s really no reason to develop it in the first place.

The second article of the series emphasizes that quality deployments matter. Deploying poorly written code leaves you with nothing but poorly written code.

In this article, I want to emphasize that quality and delivery aren’t all that matters. Let’s say you’re deploying the highest quality, most quickly deployed calculator on the planet, but your customers want a dictionary. They stop being your customers pretty quickly, even if it’s the coolest calculator in the world, because you’re not giving them the product that they want.

Value

What does value even mean? Depending on what context you’re talking about, value can come from all kinds of places.

However, if we limit the context of value to economic value, meaning “things people spend money on,” it gets a little easier. This seems like the most appropriate kind of value when talking about MoneyCode.

As defined on Wikipedia:

Economic value is a measure of the benefit provided by a good or service to an economic agent. It is generally measured relative to units of currency, and the interpretation is therefore “what is the maximum amount of money a specific actor is willing and able to pay for the good or service”?

Say what? Put simply, economic value means “something that people spend money on.”

At the end of the day, making sure people spend money on software puts dollar bills in our wallets. Turning bytecode into MoneyCode really means making sure people want what we work on.

99 Problems, But Which One?

Got Problems With Value? Software Development

Software only does one thing really well: automation.

OK, maybe two things, but I’m not much of a gamer, so I live in a world where we use software to automate stuff.

Feel free to argue with me if you want, but I really think automation lies at the heart of every value proposition in software:

  • Artificial Intelligence? Automation of mathematically complex decision making.
  • Reporting? Automation of data aggregation and delivery.
  • Instant Messaging? Automation of smoke signals. (Kidding. Mostly.)

Anywhere you look, if you think about what software really does, at the heart of it all you will find automation.

Even video games, to some degree, have automation at the heart. It’s automated delivery of entertainment value.

When creating new software, ask yourself, “What problem does the software solve?” Some problems really don’t make sense to automate, whereas there are some problems that if you can make them go away, you will automatically look like a hero.

A widely used (though likely misattributed) quote from Henry Ford comes to mind:

“If I had asked people what they wanted, they would have said faster horses.”

The reality is, sometimes you really do want to make the horse faster.

Likewise, you sometimes want to invent a new mode of transportation, but the industry you’re in has to be ready for a paradigm shift first.

Remember the coolest calculator in the world I pointed out up above? Yeah, you’ve never heard of the company that made those things—OQO. They didn’t last long even though they basically made the precursor to the smartphone. They just did it in a time when the industry wasn’t ready for it and consumers didn’t really recognize what it was.

Everyone else was concentrating on making faster, stronger hardware. The miniaturization race hadn’t really started far enough into mobile yet to make a grand impact. OQO had the right idea, but they had it at the wrong time.

The demand for their product didn’t make them economically viable. To some degree, that happened because they couldn’t earn enough marginal revenue with each unit they produced.

Here Comes More Economics!

Value Economics

What I’m really talking about with economic value is elasticity of demand. Elastic? What? I mean, yeah, I ate too much dessert and now I need to wear my elastic waistband shorts, but what the heck does that have to do with money?

It’s really just a fancy term that describes how the price you charge for something decreases with the amount of it you produce. How much will consumers stretch (elastic) to pay for what you produce?

If you remember that fancy graph from my quality post, elasticity of demand showed up in it, but it’s kind of hidden and I didn’t want to overcomplicate the economic argument about quality.

Elasticity of demand, put in math terms, is the derivative of the marginal revenue line. The larger the slope of that line, the harder it is to profit on making one more widget or producing one more quality line of code.

valuevalue

Programmers love to optimize when appropriate. When considering economic value in this case, we’re talking about optimizing the marginal revenue curve.

As the side-by-side graphs above show, the closer to “perfectly inelastic” (derivative of 0) demand we have, the more profit we get as we produce more code. We can’t keep producing forever because over time, even though our code has amazing value, it just becomes too cost prohibitive to do so.

Note: Another economic principle applies to optimizing revenue: the law of diminishing returns. Put simply, this just means no revenue line will ever be flat. Output of one more unit of work has less value than the last one made.

Now that I’ve shown you the economics, what strategies do we have as programmers to make the elasticity of demand for our services as flat as possible?

MeasurabilityMeasurability

In order to ensure our customers use the things we make, and that the things we make continue to function appropriately, we have to measure them.

One of the biggest keys you have as a developer comes in the form of measurable results. Every click, POST, and database call can be tracked and aggregated to help us understand how and why customers use what we build.

Here’s a good read about measurability—specifically, about the tools Etsy used at the time. Though it’s a bit outdated, the main takeaway here is that you have to measure everything you do as a developer because measurability turns into actionable changes.

Tools like the ones used by Etsy help us understand where customers spend their time, and which things customers never use that we need to turn off.

Here’s how I use a few that I’m familiar with right now, but this certainly isn’t an exhaustive list of tools for measuring our code.

Google Analytics

As a web developer this one is a free no-brainer. There’s even extensions for libraries like AngularJS that make it stupidly easy to track how people come to your site, which pages they visit, and how long they stay.

Tracking user movement on a page helps you  understand where to better focus your attention to achieve stability and performance, as well as highlighting areas where new innovation could really give you an upper hand.

New Relic

Sometimes, it’s all about your website’s performance. In the world of New Relic monitoring and reporting, Apdex (Application Performance Index) rules all. The way customers feel about the responsiveness of your pages and your API says everything about how likely they are to return.

After all, human attention span on the internet tends to last less than 5 seconds, so you better be sure that you’re giving customers something fast. New Relic shows you when you’re not and does a fantastic job with things like stack traces and worst-offender reports to help you understand the bottlenecks of your application.

ELK (ElasticSearch, LogStash, Kibana) Stack

Bad things happen. Sometimes they happen to good code. Do you know how to easily find the source of an error across the n-node application you’re running in your infrastructure?

A log aggregation tool like LogStash, when combined with ElasticSearch and Kibana, makes it dramatically easier to pinpoint the source of an error, which in turn makes it easier to ensure the code your customers rely on stays online.

Timing and Volume of Ideas

OQO had a great idea with terrible timing. They couldn’t survive on the market because they didn’t appropriately test their value proposition before spending too much money on producing it.

Two kinds of value proposition testing exist when you have a continuous delivery pipeline to work with: A/B Testing and Feature Throttling.

A/B Testing

AB Testing In Software Development

Whether or not you realize it, you’ve probably participated in at least one or two A/B tests if you use the internet.

The concept behind A/B testing is that there are two different approaches presented for solving a specific problem or serving a specific need. Then, the analytics tools I told you about (and others) gather statistics about user engagement, usability, and other pieces of information.

Sometimes at the end of an A/B test, a very short survey will determine the user’s perspective of the UX.

During the A/B test, a clear winner can emerge out of the two approaches. Generally speaking with an A/B test, you’ll have two different features that solve the same (or very similar) problems. One will get much more attention from users than the other. Over time, this allows the weaker feature to disappear with a feature toggle until the stronger, more attractive feature can be throttled up appropriately. This leads me to feature throttling.

Feature Throttling

Once a feature passes a successful A/B test, feature throttling allows you to gradually increase the percentage of users that can see the feature “turned on.”  As long as you’re seeing continued improvement in user engagement and enjoyment from the new feature the more you turn it on, the more you can throttle it until it reaches 100%.

This varies vastly from the yesteryears of “all or nothing” deployments. With A/B testing and feature throttling, we can easily spend time proving that an MVP (minimum viable product) adds revenue to the bottom line (or drops expenses) as we continue to empower it.

Product Ownership

The measurable “operations” side of software management should always act to inform the backlog of your development stack.

You have to make absolutely certain that your team and the product owner understand the mission of the team and always drive towards fulfilling it.

While many teams find it a bit “silly,” crafting a mission statement for your team really helps to put a specific focus on how your team creates value.

With that mission statement, you can ask each other at any time, “How does this specific thing I’m working on add value to our product?”

The Impact of Social Media

Have you ever gotten on to Twitter to find out what the world thinks of your company? If you’re a software company, you may find it pretty eye-opening, so much so that it will make you rethink how you deliver value.

Seeing your company on social media is good news—it generally means you’ve made enough of an impact that people care about what you do.

The flipside is that if you’re nonresponsive to what people say and they continue to see the problems over and over again, they’re likely to dump you faster than yesterday’s Snapchat.

The Value of Creating Value

Moneycode Value

We programmers optimize everything. I wouldn’t be surprised if someone actually automated their entire morning rituals using an army of mini-drones and Raspberri Pis—but I digress.

Optimization of value depends on ensuring you’re creating exactly the right things at exactly the right times. You have to know what customers need, and you have to know how to keep giving it to them by measuring everything you deliver.

Even if you’re a sole proprietor / freelancer, you have to be conscious about the code you write. Probably even more so, because your code is your portfolio, and programming is an art form.

Therefore, make sure you understand how code solves problems because solving problems creates value. And value creates MoneyCode.

If you're looking to give your career a boost, then you may want to consider starting up a blog of your own. You can check out my course on this for a few solid tips.

About the author

    Jason Lowenthal

    Jason Lowenthal is an Architectural Software Engineer based in Springfield, MO. A graduate from Drury University, his past work includes stints with Bass Pro Shops, O’Reilly Automotive Inc. and Paperwise. When not contributing his time and talents to his employer, Asynchrony, Jason spends his free time raising his 3 girls, and learning about new technology. You can link up with him on Twitter, too: @lowenthal_jason