Six Ways to Scale Back Your Dev Costs Immediately
Six Ways to Scale Back Your Dev Costs Immediately
In the tough economic realities of a world dealing with COVID-19, it might be time to take a look at your bottom line to see where you can cut costs.
Join the DZone community and get the full member experience.Join For Free
With the Coronavirus economic crash, companies are scrambling to reduce costs. For many online and technology companies, however, the shift to online work and online learning and streaming media means their services are more in demand than ever. So how do you address the need to scale back your spending and at the same time scale up your services? Here are some suggestions:
Assess Your Team and Resources
Personnel costs may be your largest expense right now, but they are also the only way of driving down all your other costs. You will need to reduce your technology costs through your engineering team and its core competencies, so you need to understand those competencies clearly as you construct your plan to reduce costs. Before you start laying people off, make sure you understand what your teams are capable of, and who will be instrumental in helping you weather the economic storm. You need to have a team that will fit your technology, and vice versa.
Move to the Cloud (Maybe)
Most companies will be in one of three positions with regards to the cloud: They are entirely cloud-based; they are partially on-premise and in the cloud, using a hybrid cloud infrastructure; or, they are entirely on-premise (and probably planning to move to the cloud).
In theory, because the cloud is a utility model for delivering online experiences and software, it should be cheaper than on-premise systems and architectures, which usually require a lot of expensive, dedicated IT personnel to administer. In reality, if you are seeing huge spikes in traffic because of the Corona crisis, and you are completely in the cloud, your expenses are also spiking —and if your revenue is advertising based, you might be watching your costs expanding while your revenue shrinks.
If you are gaining users and market share in the crisis, the last thing you want to do is limit your growth. So the best way to reduce your expenses as a fully cloud-based company is to maximize your use of the cloud. There are some simple things to do here:
Find Unused, Underused or Unattached Resources
One benefit of the cloud for a lot of developers is that it enables you to provision environments, applications and services quickly. Unfortunately, a lot of those deployments probably aren’t being used, and they are costing you money. You should review your cloud dashboards, find those outliers, and shut them down.
Right Size Your Configurations
Because cloud infrastructure provides for a variety of configuration, chances are your infrastructure isn’t currently tuned to the exact parameters of use; you can fix this and save yourself a lot of money.
Tune Your Environments for Actual Use
Similarly, there are always peaks and valleys in demand for cloud use, and you should configure your systems for these variations. A couple of caveats here: Container Orchestration, using Kubernetes or some other system can potentially optimize the use of your system. In practice, orchestrators can introduce a crushing level of complexity into your stack and build system, and you might not have the dev talent on hand to take advantage of this approach. If you don’t, do not use container orchestration to manage your usage deltas. Similarly, serverless functions and spot usage of cloud services can optimize your costs against use. But here again, you will be dependent not only on the skill of your dev team, but also on the scale of your enterprise. It is simplicity itself to manage 10 functions; it’s a much different challenge at 10000.
If you are only partially in the cloud, one of the best ways to reduce your costs is to move as much of your infrastructure as possible into it. In practice, however, this can be tricky, and might increase your expense instead of lowering it. A lot depends upon which components of your infrastructure remain to be moved, how old those systems are, and how talented your development team is.
Because of the way cloud is architected, it is almost never the case that you can simply redeploy an on-premise architecture to the cloud; there is usually a fair amount of work involved in rebuilding on-premise applications and services in the cloud. And most development teams will wait on deploying the most complex and difficult components of your infrastructure until last, so chances are, if you are only partially cloud-based, the easiest work has been done, not the hardest.
In a recession, you most definitely do not want to bear the expense of moving legacy systems and code to the cloud, unless those systems are absolutely and completely failing you. You must choose your next steps carefully, and — most importantly — you’re going to want to be sure that any movement further into the cloud can be done effectively by your team, and quickly.
If you aren’t in the Cloud at all, it might be cheaper for you to stay with an on-premise architecture, even if it means carrying a higher personnel cost. Many older on-premise systems are well-tuned to your business needs, and often your IT expenses are sunk costs. One issue you might be finding right now, however, is that huge increases in traffic, as many online businesses are experiencing today, are causing your systems to fail.
In this case, however, the faster path to resolving your issues is probably by modifying the infrastructure you have today for the increased load. You could also renegotiate your rates with your on-prem provider. The cost and development of provisioning an entirely new architecture may well be beyond your wallet.
If you do choose to move some components of your business to the cloud, be smartly tactical in your choice and make sure that movement would sync with the skillset of the team that would have to work in this environment. Also be aware that because the cloud is a utility system, based on transactions, it may well increase your costs to take high recurrent transaction systems, like real-time bidding, to the cloud, or high media weight systems like video or audio.
Embrace Your Host
Whether cloud-based on on-premise, probably the fastest way to reduce your technology costs is by fully embracing your host infrastructure system, and utilizing as many out-of-the-box components provided by that host in your architecture. With some providers, you might be able to negotiate a lower cost for your tech by taking your stack deeper with that provider, but the big gains here are by simplifying the complexity of your system and organizing it around a more limited set of team skills, specific to a host and those incumbent technologies. There are some other benefits, especially around security. But the big win here is focusing your team on a singular, simplified architecture and infrastructure that they know in great detail.
One thing you most definitely do not want to do as you are reducing costs is to build platform-agnostic or cloud-agnostic systems. These are very popular with a lot of development teams because — in theory — they allow you to switch from one cloud or platform provider with relative ease, and therefore negotiate better rates from them.
In practice, this approach will double or triple your development cost and complexity, and the difference in price that you might negotiate will probably be absorbed by the time and expense involved in executing this approach. Unless you have a completely top-rate engineering team who has executed against this type of infrastructure design in the past, you will lose money with this approach. And for most teams, this is a design approach you take once you have mastered a singular infrastructure, and ironed out as much value from that approach as you can.
The developers on your team will hate this recommendation, but as a business manager, I can tell you that one of the quickest ways to control your costs is to pause any edge technology prototyping and use of new technology. Dev teams should be constantly looking for a new way to build — it will keep your systems updated, and your teams engaged. But when a company is under economic pressure, you can’t afford this. Chances are your dev teams are making decisions right now where they swap out one set of tech for another that basically does the same thing.
Some of this is personal preference and some of it is the implicit experimentalism of high performing teams. But if that new tech being used in your system will not make any difference for your end-users, or absolutely help you reduce costs, it should not be implemented, because there is always, always, time and expense involved in introducing any new tech.
The best way to do this without alienating your teams is to introduce a plan to centralize and review all software contracts and frameworks your team uses — especially open-source software, which often has a lot of hidden expense if it is idiosyncratic and poorly supported by the development community. In normal times, you can afford to be loose with this type of governance, but not in a recession or depression.
It’s important to emphasize that you are pausing innovation here, not killing it. No technology organization can exist without innovating, and as soon as your costs are under control, you will want to reintroduce processes that allow you to incorporate the natural experimentalism of your team.
Optimize Your Management
One of the best ways to streamline your technology is to streamline your management of it, especially the sync between your business requirements and your tech teams. If you are an agile shop, you should be used to engaging your engineers proactively in the business management and product development process; if you’re not doing that, you’re underutilizing the creativity and problem-solving skills of your best engineers.
The point is to remove as many obstacles between product development and engineering. In a lot of large companies, these are entirely separate processes, but in technology companies these roles can easily combine, and should. Not only will you get cost savings from combining these roles, you’ll get efficiencies in terms of product outcomes.
Agile teams also need to be a little more process agnostic in terms of the ideal Scrum process; depending on the size and complexity of your organization, a scrum master could be a product owner or an engineering lead, for example. Remember that the entire point of Agile is delivery, not the process of delivery. You want to remove the steps in your development process that add anything less than critical value.
As you focus on driving efficiencies between the product development and engineering process, you want to take the occasion to tighten your focus on your business and its outcomes. Scaling down your tech might mean scaling back your business, but how you do both will depend, ultimately, on your teams and their outstanding skills.
Optimize Your Engineering Team
Finally, we come to the ultimate way to control your development costs immediately: lay off and reduce your developers. In such uncertain times, this is a very painful choice, and one fraught with a lot of business risk. Especially if you are a technology business, your teams are the life of your business, and the culture you’ve taken so long to create can be permanently damaged by the wrong approach to layoffs. So, if you are going to have layoffs, you want them to be legal, ethical and responsible.
But also: you need your layoffs to be against your new development reality and against your approach to reducing your costs. And the big danger here is development overreach. There are a lot of things your business could do, but there is a much more limited set of things your engineering teams can do. No matter your ambitions, you want to be realistic about what your teams actually are able to do. A lot of tech skills are not broad, and can’t be shifted to other work. A great iOS developer is unlikely to be easily repositioned to SQL or Java development.
So, before you do layoffs, you want to be clear-eyed about what it is you do well, and what you do not. And what you do well should determine how you approach reducing your costs across your stack. You want the size and skill of your team to fit the size and requirements of your system. Complexity here inevitably introduces cost. So, simplify.
In the end, it is probably better for your business if your technology stack is a simple monolith run by a small team, than a complex microarchitecture run by a large team, as long as that monolith delivers value to your users. And once the business environment returns to normal, you can begin once again expanding your tech stack — and your tech staff.
Published at DZone with permission of Vic Bondi . See the original article here.
Opinions expressed by DZone contributors are their own.