Be the first to like this
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 peeking at your classmate’s test, no cutting in line for lunch… or else. But is cheating always a bad thing?
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.