Can we write cheaper software?
Is running your code expensive? Do we even care about it? Does anyone of us think about writing software that is cheap to run? It is the cost our company pays every day, so maybe we shouldn’t ignore it?
Usually, when we talk about optimization we mention only computational complexity and memory usage. Is it possible to optimize the cost?
Frontent — backend
What is the point of separating backend and frontend? Why aren’t we using some tools like JSF (or their equivalents in the non-Java world)? Is it only because pages generated by such tools are difficult to customize and almost always ugly? If you have seen any enterprise application you know that ugliness is never a problem. In general the only enterprise criteria regarding user interface is “UI more similar to Excel is better”. So why do many companies rewrite their tools and decide to deal with the burden of using Angular or React to create new software? Why do we hire more developers instead of using some JS-generating tool?
Is it cost-effective?
A few weeks ago I heard an interesting opinion (kudos to: @lukaszbyczynski). Every time you move computation from your server to the client you save money. Processing in the client’s browser is free for us, isn’t it? Do we even think about it while we write code? I have never bothered with the financial side of running my software. Maybe it should change?
Why if we measured how much we spend on running every service? Why if we displayed such information as one of the application metrics? Would it make a difference if we asked ourselves not only “Why is there 10% errors more than yesterday” but also “Why does this service cost us 30% more than last week?”?
What can we do?
Should I remind everyone what computing time is cheap but it is never free? Should we process everything we can in the client’s browser and let them pay for that? Should our backend services skip some processing steps only because browsers can run code too?
Should we? Seriously? Is it really that simple?
Remember that data transfer is not free either. Do not send too much to the client because you may either reveal more information than you should or pay way to much for it. Even if you do not pay for every transmitted GB you need to remember about the bandwidth.
and mobile clients…
Please consider detecting the type of client’s device and acting accordingly. I am really annoyed by mobile applications and mobile websites which are totally useless when I am out of LTE range.
Sometimes I wonder why we still have other mobile data transfer standards. Obviously, such outdated standard are useful for some IoT devices. Why do mobile phones still support them? Would anyone notice the difference between not having mobile internet access or using a terribly slow network?
Also, regardless of what advertisements claim, there is no such thing as unlimited data plan, so maybe you do not need to send 4MB images just to display them on a mobile phone screen.
One more thing, the most important one, do not drain my phone battery by running too much code in the browser unless you want to lose a user.
An article published a few months ago by StatCounter reveals that mobile and tablet internet usage has finally surpassed desktops. Therefore maybe we should rethink the idea once again.
Is it really cheaper to write (and maintain!) the same code twice than processing as much as possible on our servers(/virtual machines rented from a cloud provider/FaaS/anything else we pay for)?
It may be the right solution for companies having a lot of users. Everyone else should focus their frontend development only on making the user experience as good as possible.
Last but not least, can we focus on the moral side of that idea for a second? Is it fair to use client’s resources? Should we get their permission or compensate for it?
Maybe the only thing you should remember about is the fact that running your software is not free and sometimes you should take that cost into consideration.
Did you enjoy reading this article?
Would you like to learn more about leveraging AI to drive growth and innovation, software craft in data engineering, and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- MLOps engineer by day
- AI and data engineering consultant by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz
- Mastodon: @email@example.com