Basic Business Economics for Developers
Are you a developer? Do things like revenue, return-on-investment, payment terms and capital seem irrelevant to your job? I’ve got news for you! Having a basic understanding of business economics will have a significant impact on your success now and for your entire career.
Why? Because for most of us, we will work for a company that has hired us to help them build revenue and achieve profitability. Our ultimate bosses speak the language of finance and if we cannot communicate in their language, we can’t discover what’s important for the company’s success. We can’t argue our perspective forcefully and we’ll be sidelined as techy-geeks that don’t understand business. Sadly, that’s often true, and it doesn’t need to be. Behind the jargon are some really simple ideas that have practical applications to our work.
Behind the jargon are some really simple ideas that have practical applications to our work.
Revenue, cost and profit
In the most basic model, revenue, cost and (net) profit are equated as follows:
Or, as a business leader would prefer to see it:
This is a waterfall chart and is used extensively by those big strategy companies. There’s a reason for that, it is extremely clear. Actually, PowerPoint does a terrible job with it’s colour handling, which is why I’ve recoloured it to add emphasis to my point, “what’s the profit?”
Cost itself is generally too vague, and so we can break that down further. In the domain of software development, costs might be broken down as:
- Facilities: physical office premises, corporate networking, email, telephony, etc.
- Direct staff costs: salary, pension contributions, employer medical expenses, individual staff equipment, travel expenses, etc.
- Development and other non-production systems used in the design and build of production systems
- Production systems and all operational and security facilities that support them
- Delivery chain (sales/media channels, supplier margins, etc.)
Timing
It’s not good enough in business to have a great idea. You also need to have it at the right time. Business finances are no different. You see these graphs are great when a business has reached a steady state, but if you are just starting out they don’t give you the full picture at all.
If your company is betting on revenue from big corporate customers, there’s a very long period of waiting between your first release into production and actually getting that payment cleared into your bank account. That’s assuming that they will sign for your first version and not require you to make significant additional investments to address their corporate needs (think SAML single sign-on, tenant isolation, enterprise key management, third-party penetration test reports and repeating schedule, and so on). That’s if they do like the product. And of course, to build market awareness and gain traction your company is probably going to substantially discount your product as well.
All of this means that your business leaders are acutely conscious of the money they are spending while waiting for your product to be purchased.
All software is not created equal
In my experience, there are a few things that are important to consider in respect of cost that can have a profound impact on the viability of software development:
- End-to-end product delivery productivity. This is why I’m an advocate for Agile and DevOps. Many businesses waste countless hours due to inefficient and ineffective policies and practices. We can do much better, and not just with automation. Faster delivery, earlier involvement of (potential) customers, policies adapted to real needs and concerns and not just garbage pulled in from a vendor selling snake oil
- Elastic and price-conscious infrastructure choices with cost deferral
- Revenue awareness when designing software
End-to-end product delivery productivity
It will never be possible to please everyone, but your team needs to work together across product development, marketing, sales and IT, with customer needs foremost and operational needs close behind.
As a developer, you can ask questions about what is valuable to the customer, about whether a particular process or procedure can be changed, or what software tools you need to better perform your job.
Being able to articulate how your productivity is tied to the company’s revenue makes it much easier to argue your case and get buy-in for your ideas.
Elastic and price-conscious infrastructure
Running your own dedicated ElasticSearch or MongoDB cluster has a very different cost model versus using a PaaS model or a different platform entirely. None of these are bad technologies themselves, but anything that has a fixed operating cost is much harder to justify than something that can scale easily with your customer demand.
Can you make use of spot-instances to gain up to 70% of your EC2 hosting costs? What would the impact be on your software architecture? What about serverless designs such as Lambda? Do you need your test environment running at the weekends or always at full scale? Can you elastically scale your build pipeline based on the number of jobs? Do you even know what you are spending?
These are no longer other people’s jobs. This is our job, as software developers, architects, infrastructure engineers, DevOps leaders and CTOs. So do a bit of reading on what different things cost and how this can change how you architect.
Revenue awareness when designing software
At a lower level, revenue awareness means that we reconsider options such as on-disk versus in-memory data structures, programming platform, data storage with a consideration of:
- runtime demands
- availability demands
- networking demands
- storage demands
For instance, CPU is far more elastic than RAM. When you are running Kubernetes, or other container platforms, it tends to be that you have an excess of CPU that is underutilized and you are scaling the number of instances based on the amount of RAM needed to host workloads. Quite simply, this means that a 4 GB JVM process will cost eight times as much as one that has been designed to run as a 512 MB process. Nothing is wrong with using 4 GB or even 400 GB, so long as it makes good business sense. But as developers, we need to be conscious and careful in how we design software and articulate these choices. A single 400 GB workload on EC2 would require an r5a.24xlarge instance and would cost around $4k per month for an on-demand instance. Repeat that for your development and staging environments and you can quickly see how the cost multiplies. Compare that to a t3.micro instance with just 1 GB of RAM and that would cost approximately $8 per month, again for an on-demand instance. You need what you need, but as developers we are often in a position to decide what we need.
Availability demands similarly dictate how much redundancy is required and it is a factor of the number of instances and also how quickly a new instance can be made ready. If your application can boot up in a few seconds, you don’t need a huge amount of redundancy. If it takes tens of minutes to launch and reach a steady state, then you will need to have more redundancy to maintain the same degree of availability.
Networking costs can also be a surprise. There are two main factors to consider:
- Will I need a bigger instance to support the network throughput?
- Will I introduce significant cross-region or cross-availability-zone traffic?
If the answer is yes to any of these, costs can ramp up quickly.
Data transferred “in” to and “out” from Amazon EC2, Amazon RDS, Amazon Redshift , Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances or Elastic Network Interfaces across Availability Zones or VPC Peering connections in the same AWS Region is charged at $0.01/GB in each direction.
Data transferred between Amazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache instances and Elastic Network Interfaces in the same Availability Zone is free.
These costs are generally negligible until you introduce heavy networking traffic, but once you do network traffic can be of a similar cost to your EBS storage or in some cases your instance hosting!
Finally, storage costs can be overlooked. As well as your runtime storage, you also need to consider backup volumes. Worst case analysis for 500 GB of storage and 14 days of daily backups in EBS:
- 500 GB @ $0.10 / GB = $50/month
- 500 GB * 14 days @ 0.05 / GB = $350/month
- Total cost: $400/month
In general, it will be much lower due to snapshot deltas, but that depends on the usage pattern you make of the underlying disk. Keeping in mind the worst case cost helps to ensure that you know where you stand. In one system I saw, the worst case cost was actually very close to the real cost. You can sometimes mitigate this by locating your data traffic into different disk volumes based on how they are used.
Often, your data systems will operate with active replicas, and so this number will be multiplied by the number of replicas (and of course, you’ll backup all replicas!).
It’s quite possible to reduce these costs by reducing the resilience (it’s actually pretty high if you are operating replicas and backups of all the replicas, but at the same time it adds extra pressure on your operations team. And that might be you.
Getting on top of costs
I find the easiest way to think about these costs and the choices that you have to make is to keep in mind the notions of cost of transaction and price of transaction. The transaction is something you are selling. It could be a minute of use of your product, or it could be the execution of a single high-value feature in your product. It should be the reason why a customer is using your product.
The price of transaction is the amount you expect to charge, on average, for a single transaction. It may not be billed like this, but it is something that you internally agree is representative for the use of your product. It may be much higher than most customers actually pay if you charge some customers disproportionately (as is the case for most software targeting enterprise customers!).
The cost of the transaction should include all of the cost factors I described at the beginning of this story. Some portion of that is associated with the running of your software. If your software can’t operate within that budget, it is not fit for purpose. Either the software needs to be changed or the business model does. Pretending otherwise is not helpful. Perhaps you need to reduce costs. Perhaps you need to increase revenues. Or perhaps you need additional venture capital investment to help you get to the next stage.
I hope this short story helps you communicate with your business colleagues as you develop your next piece of software.
This post is also published on my blog at https://stevehorsfield.wordpress.com/2019/10/09/basic-business-economics-for-developers/.
