#27: Don't Break the Bank: Smart Spending on Software Architecture
Budgets and software architecture go hand-in-hand. If you don't keep an eye on your budget, you are asking for trouble. That's why it is so important to give it the attention it deserves.
An integral element that we engineers need to remember is the budget within which we operate. It might be enormous or minimal. Fixed or flexible.
But there is always a budget.
As software architects, we need to observe it, but we don’t have to think about it all the time. If you exceed the monthly budget by a dozen dollars, it is unlikely that something terrible will happen. But it would look different if your logs generated costs of $500,000 while it was expected to be around $10,000.
That is why making informed decisions with your team is crucial. Compare at least two solutions and analyze them carefully. If the budget is tight, you will plan the architecture differently than if it is flexible, where you can maneuver a bit.
Tight budget. There is no time to learn anything new; together with your team, you must look at your current skills and select the approach based on them. It is similar to a sports team: when a coach joins a mid-tier club, they adapt tactics to suit the players they have.
Flexible budget. There is a space to learn something new, spend time on spikes, compare tools, libraries, etc. However, this does not mean you should choose all the fancy technologies you have ever heard of. I know cases where the team gold-plated every detail of the application with cutting-edge components and continuous deployments, only to run out of budget along the way. The app was never released. In the worst-case scenario, one company went bankrupt.
Budgets will usually look different, depending on the company type:
Your own business without external financing. You will try to cut all costs to a minimum. Every extra few dozen dollars will weigh you down. I recommend that every programmer try it because it changes the point of view. When we work for someone, it usually doesn’t matter so much to us.
Startup. Depending on the financing type, there will be more or less flexibility on the budget but much pressure on product delivery. This means that you cannot invest too much time in learning new things, especially before releasing the minimum viable product (MVP).
Small and mid-size companies. Budgets might be higher than in previous cases, but business looks at every cent spent. The rule is simple: you need to earn first, then you can spend part of it.
Large-scale organizations. They have the highest budgets and expenses. You usually plug your application into existing infrastructure so that the initial costs might be smaller. These costs may go unnoticed up to a certain point. However, this does not mean that you should not watch out for them.
The rule of thumb: Always treat it like your own business, minimize costs where possible, and continue expanding your knowledge.
When looking at costs, they are primarily dependent on:
Running costs. It does not matter where you run your application, it always generates monthly costs. The more components you add, the higher costs will be. Start with the minimum infrastructure necessary.
Cost as a consequence of the choice. If you decide to use a language, framework, or library that you do not know yet, you have to learn it first. The more new elements you add to your application, the more there is to learn, which can slow down development. As a result, costs will be increased.
Cloud providers might offer a significant infrastructure budget for free in the first year. However, adding too many components and using too many services can lead to enormous costs in the second year. As a result, you might spend 10 times more than you earn.
What always works great for me is to look at running costs in percentages rather than focusing on specific amounts. As you have probably noticed, these costs can vary depending on the scale of the business. So, instead of looking at something that costs $100, I am checking what percentage of the current costs this will absorb. With current costs of:
$100. 100% more than I pay today, so I will probably be contemplating this for a few days.
$1,000. 10% of the current costs. Not as much as in the previous case, but still a lot.
$100,000. 0.1% of the current costs. Minimal impact on the budget, let’s add it.
Another way to consider costs is to calculate how many software licenses you would need to sell to cover the expense of additional components.
So, if a component costs $1,000, and each software license is sold for $100, your company would need to sell 10 additional licenses to cover the cost.
You must always consider all of this. In some companies, exceeding the budget by $10,000 might not be a big deal. However, there are also companies with minimal budgets, and you will need to carefully evaluate whether using specific components makes sense.
How do you approach the budget topics in your applications?