Day 10: Those Times When Cheating is Good.
From an early age, we are told that cheating is bad. There are rules we’re supposed to follow, and breaking these rules – we’re told – is a big no-no. No ice-cream before dinner, no peaking at your classmate’s test, no cutting in line for lunch… or else. But is cheating always a bad thing?
Dominic and Scott from The Working Group came up from Toronto to talk to the companies about those times when cheating in development can be good.
Bad cheating breaks the law, puts people at risk or has severe negative consequences. If you’re making a program to run a nuclear reactor: don’t cheat. If something goes wrong then there will be very bad consequences.
Good cheating is like a magic trick: it’s a method to achieve a desired effect. Just don’t get caught. Getting caught ruins the magic and gets you in trouble. Do things “wrong”, get dirty, use hacks, and optimize for very specific cases. Do all this in order to deliver the desired effect.
Applications capture, retrieve and display resources. These resources have costs, such as the cost of transmission, processing and storage. Different resources have varying probabilities of being required; some may be requested and others not, some may be requested frequently and others rarely. These are all things to consider when deciding what processes can and need to be optimized, which will in turn help you choose from your magic bag of tricks.
Here’s a quick barometer for deciding when to cheat:
- Requests that are free or cheap to deliver and are rare are not worth optimizing since these are essentially effortless already
- Requests that are expensive but rare aren’t a priority, feel free to procrastinate on these
- Requests that are free or cheap and happen frequently are the fun ones to optimize
- Requests that are frequent and expensive are your big wins… if you can figure out how to optimize them.
There are many ways you can use performance cheats to optimize your application. A big part of cheating is first deciding when ‘more is more’ and when ‘less is more.’ For example…
Faster is not always better, sometimes you might actually want to make users wait longer. You can make something appear important by taking longer to load, creating the impression that the user’s request is hard and requires a lot of work (think airlines). Just make sure you keep your delay proportional to the significance of the request, and make sure you keep your users informed via a spinner or progress bar. Making users wait more for more expensive requests makes users less likely to engage a feature needlessly.
For resources that users don’t see, load less. You can fetch things on demand or practice “lazy loading”. Apply the refrigerator light principle and make it seem like it’s always on. On the other hand, for resources that your users do see, fetch them ahead of time or practice “eager loading”. In these cases, apply the boy-scout principle and be prepared.
Save less: trim, crop, shrink, and strip out redundant or duplicate content. Go for one-size-fits-all when possible. But have everything that is important ready instantly, which in some cases may mean saving more.
The fastest database call is the one never made. Cache high frequency requests that are cost-effective; for high cost requests, cache only if it’s likely to be used more than once. But be careful what you cache, since cache mistakes can be very embarrassing. Caches can make updates take longer and can be very hard to invalidate. Also consider that running without a cache leaves you with headroom.
Sometimes you need to distribute more. Push data closer to your users, go for client storage and content bundles. Other times, you need control over structure, strategy and technology, so distribute less.
Apply minimalist principles. Delete data that you are no longer using, send archives to cheaper storage systems. Purge. But some unpopular things matter and shouldn’t be purged. Dump these on the cloud, keep them cached longer, or pre-render them.
Most resources benefit from some sort of compression. But remember that compressed data can’t be queried and databases can’t interact with compressed data.
Indexes massively reduce retrieval time. A query with a tuned index = bliss. But indexes don’t always get used, and every index makes writes more expensive. Rule of thumb: awkward and fast can be better than easy but slow.
The bottom line is that, like magic, performance cheats are about perception. The key to remember is that if an application feels fast to your users, then it is fast.
Do you have other cheats that work like magic?
