On Value to Complexity Ratio

2025.02.23

LXXXVIII

You want to make it as easy as possible to get as much value as possible, regardless of what you’re doing.

In other words, in most system, a good goal is to maximize (Value Available) / (Complexity needed to get that value)*.

Let’s call this the Value-Complexity-Ratio (VCR).  VCR is somewhat of a generalization of “time to value.” Why not just use time to value? Well, I think VCR is maybe easier to apply to how you think about building things overall, rather than just applying it in terms of user experience.

VCR = (Value Available) / (Complexity Needed to Get the Value)

As an example, programming languages have incredibly high value available, but they also have very high complexity required to get that value. Overall, English also has high value available, but lower complexity required to receive that value. In other words, I’d think the VCR of English is higher than a programming language. 

In your own systems (your business, product, relationships, etc), you can maximize the VCR by:

1. Reducing complexity more than you reduce value

2. Increasing value more than you increase complexity

Value and complexity do not always have to go up and down together. There are ways to increase value available while REDUCING complexity, and when you can do that, you definitely should.

A lot of the time, though you’ll likely be moving the two measurements in the same direction and need to increase value more than you increase complexity or reduce complexity more than you reduce value.

Re: option 1, last week, Jack & I got very good feedback about how to reduce the VCR on our frontend—we were told a number of ways we could reduce the complexity required to get value while maintaining value. “DRY” is a good heuristic that captures this.

Re: option 2, I don’t think BirdDog as a product would be able to provide nearly as much value to users as it does right now if we did not aggressively wring out every drop of value as we can at our given level of complexity.

*I don’t know the best way to calculate the actual ratio, but I would think you could likely translate both value and complexity into dollars. Perhaps (minutes [saved | expended]) (cost of those minutes) is an accurate function to calculate this.

[UI/UX Reduction]

One of our prospects gave us a lot of feedback on the front end of our application last week, much of it very good and easy to action.

As an example, right now, we have two separate tables, one for companies a user favorites and then one for “the rest” of the companies that they haven’t favorited. He pointed out how much simpler it would be if we added “favorites” as an option to our existing filter system and remove it as an independent table. 

This is a very simple and elegant fix that reduces the complexity required for the user to get the same amount of value from the tool. One table with a filter is less complex than two tables with a filter, even if we add another button to the filter.*

This seems like an obvious change to make, but for whatever reason, we did not notice it until he pointed it out for us. 

*This seems intuitive enough that it’s not worth “proving”, but I do imagine one could come up with some sort of robust, relative measure of complexity for different versions of the same tool. You’d only want this when you started running into tradeoffs that were not obvious. But by that point, you might just want to a/b test.

[Reusing Code]

DRY is a good way to think about keeping complexity low while maintaining value. It is a programming heuristic:

DRY - Don't Repeat Yourself.

It means if you write code to do a thing, you should not rewrite that same code to do the same thing somewhere else. You should just use the code that already works. 

This heuristic is usually applied on a quite small scale. An example from the BirdDog code base is using a customer error wrapper for handling errors on a lot of functions. The error wrapper is 37 lines of code. When we apply it to a function, it turns what would be might be, on average 5 lines of code into 1 line. It’s used about 150 times, so it saves almost 600 lines of code.

If the total number of lines of code for a project is even a semi accurate measure of complexity, then by coding with DRY in mind, we are reducing the VCR of our code base by reducing the complexity while keeping the same level of value.

This is similar to what we achieve by removing the redundant table on the front end. The same amount of value is available and it take less complexity to unlock it.

This might seem like an obvious trade off to make, but it is becoming increasingly non obvious as generative ai becomes more ingrained in how we build things. When you are coding with generative ai, the cost of writing boiler plate code becomes almost 0 (ai can write redundant code for you instantly). So, it is easy to build up A LOT of code you don’t really need.* 

On the other hand, it is pretty tricky to get a reusable function right. You have to spend time & effort writing a function for long term gains that might never materialize if you don’t make the function general enough.

*There was a study showing that as gen ai has been more widely adopted by programmers, the quantity of exactly duplicate code has gone up.

[Bone DRY = High VCR]

While at a smaller level, DRY helps you control complexity while maintaining value, taking it to the extreme can also help you create far more value at a given level of complexity.

I believe that this is one reason BirdDog is able to provide an outsized amount of value for it’s users given the size of our code base (~20K lines) and dev team (1 person)—we have taken DRY to the absolute extreme, albeit at a bit of an abstract level.

Without getting very specific, the core code that lets us do research on a user’s prospect list is also the core code that lets us update a user when something changes about their prospects. 

These are two really powerful functionalities that we could probably sell as separate products—the initial research and the constant updates on it.

Beyond that, we’re working on a feature to find lookalike accounts for our users. This could be complicated if you want it to work well, and not so complicated if you don’t care.

That being said, this experimental feature actually seems to work BEST when it relies on big parts of the same code that already lets us do research and send alerts. We get to borrow the complexity that we already know works well.

All of this makes it much easier to scale the product—increasing the ability of the pipeline to do one of these things, for the most part, increases its ability to do the others. On the other hand, if the initial research, alerts, and finding new accounts were disparate functions, increasing the prospects we process on a daily basis at the rate we are would be a nightmare.

This, the extreme version of DRY, Bone DRY if you will, let’s us wring out all of the value we can at the given level of complexity by taking the functionality we have to it’s extreme but natural conclusion. This increases VCR by raising available value to the users from the pipeline while increasing complexity at a much slower pace. 

To make it somewhat real with numbers, I would say that adding this lookalike feature increases the complexity by at most 20% while increasing the value by 1.5x in the worst case and by 5x in the best case.*

So, worst case VCR for the lookalike feature is 7.5 (1.5/.2). Most of the stuff we need to make it happen is already there.

Another way to look at VCR is “return on complexity”… we’ll likely revisit this idea in more depth later.**

*Re complexity increase, we’re adding ~1000 lines of code and doing some light refactoring to the main function. 20% may be high. Re value increase, the 1.5x is the multiple we’re quite confident we can increase price by, but we’ll see.

**Part of me is envisioning some sort of “efficient frontier” for return on complexity rather than risk.

[Put Simply]

My formulations for “VCR” or return on complexity are somewhat though experiments. 

What’s not, though, is the simple truth that the more value you can make available in exchange for a given level of complexity, the better off you will be.

Live Deeply,