We love fast software, at all levels: as instant as the software is, a better perception of engineering quality we have.
However, speedy software isn’t a feature you can add in a product sprint. It’s a constant mindset, and the only way to achieve that is going fast slowly.
But how to constantly improve something that constantly change?
If you want to write fast software, use a slow computer Dominic Tarr.
There are a set of things that never – or rarely – change, being anticipation the key to performance.
Yeah, I know, it sounds very obvious, but most of us, as programmers, think code and infrastructure are separate things, while they are very linked.
In fact, if we want to think where physically the software is running, the differences are even more obvious.
The smarter way to improving software is by identifying the slowest part that is being used more time. Then the speed up will have a significantly higher impact than improving other minor software aspects.
That’s is known as Amdahl’s law.
If you want to be fast by default, you need to understand what is running under your software:
This a primordial step to identify what feels slow and where slowness comes from.
Choose what to improve is the hard thing, but it makes unnecessary to optimize all the things.
Most common improvements are actually time optimizations: Instead of serving a real time™ – and costly – response, we can say it is OK serving a pre-calculated response but much much cheaper.
They are done every time you: