Cost-Driven Development

Write code that makes money

I often describe my career as a lucrative hobby. As a kid I realized that I enjoyed writing software. One thing led to another and various companies decided to buy me food and pay my mortgage to write their software.

My origin story is not unique. StackOverflow’s 2016 developer survey showed that almost 70% of all developers are self-taught. Their 2017 survey revealed that over 90% of professional programmers have attended some college or university. Stated differently, the majority of developers, while college educated, eventually abandoned their major to pursue programming.

While I can’t speak for everyone, I started coding because it was enjoyable, but I continued coding because it was accessible. I began my career pursuing mechanical engineering which I enjoyed, but CAD software that cost $80k per seat was a little out of my price range as a high-school senior. Programming was something I could do in the evenings on the cheap. Today, between free editors, StackOverflow, YouTube, and millions of dollars being invested in education, software more accessible than ever as a “lucrative hobby.”

The ability for a company to do anything comes from their ability to make money. A software company that doesn’t make money is just a software club.

But software as a hobby and software as a business are two very different things. The hazard of software as a hobby is that, by default, we tend to be driven by what makes software fun. I’ll spend time refactoring code because I want to try out a new pattern. I’ll use a new framework because it seems interesting to learn. I want to use graph databases because I’ll get more cred at meet-ups. You get the picture.

In business, cash is king. The ability to hand out paychecks comes directly from the ability to sell software, not the inner satisfaction that comes from writing it. In fact the ability for a company to do anything comes from their ability to make money. A software company that doesn’t make money is just a software club. Granted, I want to work somewhere where I can write code for fun and profit, but at the end of the day, any conflicts of interest between the two must be resolved in favor of profit.

While I still have the privilege of working on whatever projects I want at home, in my professional life, I have learned how to think about software as the answer to one of two questions: how does an idea make money and/or how does it save money?

Ship Highest Value First (Make Money)

Consider the following graph:

This mildly successful company sold $100k of software per month for one year. One way of calculating “top-line sales” for such a flat year is to multiply monthly sales by 12 months: 12 x $100k = $1.2M. But another way is to calculate the area under the curve. Don’t worry, I’m not going to get into integrals here, but looking at the area, specifically how we can maximize the area, is a helpful exercise. Consider another graph:

You can see that a feature (red block) is completed in December so the sales go up. Because the $50k bump happens so late in the year, the impact on top-line revenue is smaller than had it happened earlier. Delaying the addition of value delays revenue. In fact, the opportunity cost of waiting to increase sales until the end of the year (instead of doing so 10 months earlier in February) is $500,000. By Christmas, there is literally half a million dollars missing that could be spent on bonuses, brand new MacBooks, a company trip to Hawaii, or other very important businessy things.

Any software project or feature can be thought of as having two dimensions with respect to the graphs from above. The “width” is the duration or the amount of development time it takes before a feature can start making money. The “height” is the amount of revenue that a feature can expect to generate once it’s put in front of paying customers. (That value is often referred to as the “cost of delay” as it represents the opportunity cost of delaying the release of a feature.) As you can see, various projects and features will have different “shapes.”

The Usual Suspects

Regardless of the overall size, you’ll see slim features, flat features, and generally squarish features. Keep in mind that even though a feature consumes development hours from day one, it won’t generate any return on that invested time in the form of revenue until it ships. This means that to push the revenue curve up the fastest (and thus maximize the area under the curve), you need to start with the slimmest feature first. Let’s take a look at how the order of features affects revenue. Here’s what it looks like to prioritize flat features first:

Flattest Features First

Here is the difference between flat-first and skinny-first expressed as opportunity cost:

Difference when prioritizing skinny features first

It’s not the height or width of a project but rather its aspect-ratio that correlates to the best year-end numbers. This means that even if a project is short (it’s not going to bring in much money) if it is super narrow (it can be knocked out in a few hours) it is the most valuable feature (it will have the biggest effect on revenue).

This is really just a visualization of the CD3 (Cost of Delay Divided by Duration) prioritization methodology. The “shape” of a feature can be calculated by the estimated impact on sales (cost of delay) divided by the estimated time to deliver (duration). The units of such a calculation are weird and the resulting numbers are based on only estimates, but they can still be used to compare the priority of features.

If nothing else, the process provides a meaningful framework for development and marketing teams to negotiate what gets done first. When estimating hours or “story point” for a feature, try getting project stakeholders to give an “opportunity cost” estimate as well. It doesn’t have to be in dollars; 1 to 5 start rating scale could work too. In such a case, dividing the “stars” by “story points” will give a usable CD3 value.

Sometimes, the most fun projects are the “flattest.” In terms of making money, flat features will never be the highest priority. But all is not lost! Remember, ideas can either make or save money. So let’s take a look at reducing cost.

Reduce the Cost of Quality (Save Money)

If you have been in the software industry for at least 10 minutes, you have likely worked on a project that started out fast and clean but eventually grew into an absolute monster as time passed. The last few bugs were ridiculously elusive and it seemed impossible to prevent stakeholders from requesting just “one” last tweak.

One way to grapple with such frustration is to think about writing software solely in terms of increasing quality. The default state of a feature is to not exist and a non-existent feature could be considered to have zero quality: it performs zero of its required functions. When focused on quality, the developer is motivated to quickly get a feature to the point that users want to pay for it (a quality product) rather than being motivated to only add lines of code (a “done” product). Take a look at the timeline below:

Linear Quality over Time

Quality increases over time until the feature is done. (In this case “done” means “making money”.) But in reality, the quality becomes more expensive as time goes on thus the real timeline will look more like this:

Logarithmic Quality over Time

Looking at the increase in quality this way makes it clear why the end phase of a project can drag on and on especially when it takes a lot of time at the end to ring out those last few drops of quality. By inverting the axes and describing duration more generally as cost, we can see how the cost of that quality increases exponentially:

Exponential Cost of Quality

Given unlimited time and resources, a developer could achieve an unlimited amount of quality. In the real world, however, there is a budget which serves as an upper limit on cost. There is also lower limit on quality and a product needs to meet or exceed that limit in order to be marketable. These limits are shown in the following graph:

Budget and Marketability Limits

To ship a quality project within budget, the cost-of-quality curve has to cross the marketability boundary at or below the budget limit. If your curve tracks too high, you will run out of time, cash, or other resources before the project is done enough to sell. A low curve rewards you with the optionality to go to market early and under budget (which stakeholders never complain about) or at budget with an impressive level of quality (which users never complain about).

Initiatives that reduce the cost of quality don’t usually produce a directly marketable product. For example, no potential customer is going to make a decision to buy based on how well-factored your data access layer is. This makes them very flat because no matter how quickly they can be completed, they have little to no direct marketability. Therefore, when negotiating the priority of flat initiatives such as refactoring code or rebuilding a feature, take care to express how they will reduce the cost of quality. Dropping the cost-of-quality curve has the effect of reducing the “width” of tasks that follow. Take a look at how working a flat but cost-saving task increases revenue (compared to previous examples):

Effect on CD3 of refactoring to reducing the cost of quality

In this example, a mid-length refactor happens right after the first (green) task. As a refactor, it doesn’t have any direct marketable value, so it has zero height. However, because it reduces the cost of quality for all features that follow, all of the remaining blocks are cut in half. (These are just examples, obviously YMMV.) The first result is that the orange project is released later than it would have been without the refactor and consequently costs “3 square units” of revenue. However, by the time the blue feature is released, everything is back on schedule. The last two features (red and pink) are actually completed early!

From a revenue perspective (area under the curve) we lost 3 units on the orange project, but gained an additional 3.5 from completing the red and pink features early. This is an example of how an initiative that doesn’t have any direct marketable value can not only reduce the cost of future projects, but actually net more revenue by the end of the year!

For those of us developers who have a unwavering love for our craft, there will always exist a bias to make decisions based on our passion for coding rather than profitability or cost savings. The concepts above represent just a few ways to think about software from a business (read: financial) perspective. There will always be more frameworks to learn and patterns to explore. If you absolutely MUST work on that next shiny thing but can’t make a solid value proposition for it, keep it as a hobby project. Definitely pursue the fun stuff, but always keep in mind that as all companies must do, software companies must make money to survive.

Keep work projects profitable and write code that makes money!