Published on:
Smolbig.com
It is all connected. Happy users, happy management and a happy planet. Management wants happy customers because it is good for conversion, prevents churn and will help the company generate healthy profits. In the case of internal tools it will make your employees more productive, which leads to higher margins. This might sound boring, but it is good to understand the connection.
In short, happy users is key. And they like snappy apps that are optimized to their needs. But how does performance fit in with less budget and a happy planet?
Kinds of performance
In general when you think about performance and optimizing it we think about lower latencies between action and reaction, but there is more to it.
More resources
A common and easy fix for back-end related work: bigger machines and more nodes. Throwing resources at it. This is an approach that works quickly in the short term. Long term you need more and more, long term it will put pressure on maintainability and your Return of Investment (ROI).
Optimizing workload
Performance isn’t latency alone, but a puzzle to optimize your workload and try to do more with less. An optimized workload will need less resources and have lower latencies as a side effect.
Let’s do an example. If you have an app it can be great to have API’s to do all the work and keep full control, but I bet you can find features in your web or mobile application that can be done on the client. This gives the ability to make it offline available and would improve latency a lot. Mobile devices like laptops and smartphones are very energy efficient too.
Apart from the performance improvements you will save a roundtrip over the internet and you will need less resources to run your back-end. The result is you need less budget and you will have more revenue, while having less impact on the environment.
Another example, are you running big testing pipelines every night? Stop running them on weekends when everybody is off. Or use a tool like nx to run jobs in your pipelines on changes only, instead of your entire codebase.
I am not saying that all workloads should be done on the front-end or you should stop running pipelines. There are many strategies to adjust the architecture of your application and optimize your workload and these are two examples. Be creative and work on the puzzle.
Recurring vs. one time cost
Now you are probably thinking “…but I have a full backlog, working on this performance puzzle will be even more work, this will slow us down, this could even be more expensive!“.
With performance and architecture you always have to be careful not to overdo it and there will be cases that it will take extra effort. The art is to find the sweet spot between effort and value.
You need to ship, it will never be perfect and you can always improve things in iterations. That shouldn’t be an excuse to don’t put effort in this. Even when it takes extra time, it is a one time investment. You spend that time/money once.
Spending too much resources is recurring and even more important: it scales with the amount of work your app or pipeline has to do. Great chance that this approach will have a bigger impact on your budget.
Process, not project
Your application grows over time. Your resources will grow over time. If you don’t make it part of your product development process it will keep growing out of control.
It will be a big undertaking to cut back and it is hard to make time in your roadmap to do is as a project, that is never going to happen and you know it. Even if it does, after you finished the project it will grow back again. This approach doesn’t sound efficient.
Make it process, not a project. Like maintenance and bug fixing, there should be dedicated bandwidth for this.
A good way could be to make it measurable in automation and work with performance budgets. Make it part of your requirement checklist to remind the team during the work on features to think about it. Asking questions about performance impact during refinement, dedicate extra time to the backlog item when improvement is needed or to include additional work for the proper approach.
The big impact
Impact on the environment is a shared responsibility, everybody needs to take action. The trend is to make a difference by turning your lights off at home, use LED’s, don’t shower excessively, better isolation, getting solar panels or build a new house with heat pump.
That is a good start, but the biggest part of global emissions are made by companies. They have scale. To make an even bigger impact you need to make an effort at work in addition to your private life.
This is a shared responsibility, like at home. That means we all have to try our best and move the needle together. In IT we use a lot of resources, and a lot of them wasted.
You can make a big impact.
Work on the puzzle
Product development is a puzzle, a creative profession. Think about the performance of workloads and how you can optimize them. An interesting challenge by itself.
By making the connection between workload, resources and money. You can create change in an organization, even if not everybody is concerned about the environment.
Less waste, more ROI.
Final thoughts
This was me thinking out loud about being less wasteful with resources in IT and what you can gain from that. I think the puzzle of product development is always interesting, what to work on, how much effort goes into something to make it great and without overdoing it. Perfection doesn’t ship.
I think it is interesting to find the best ways to make it more measurable and find best practices integrating this in the product development flow. Please let me know if you have thoughts on this, would be great to learn from each other! Send me an e-mail or reach out on X.