This blog post covers: the practical definition of what heuristic is, example of how imperfect heuristic may solve a problem we're not sure exists, what does it mean "everyday heuristic" (that is not really ad-hoc) and whether it's fair to call heuristic a "short-cut".
It's not (& it never was) a surprise that software engineers are much better with terms, concepts & abstractions present directly in the code. I've seen several tech people kinda confused when discussion skewed towards more general problem-solving space - they didn't seem to have a good grasp on some basic terms & one of these were "heuristics" - a very useful concept that is extremely applicable in your (software crafts(wo)man's) everyday work.
What are heuristics then? I'll spare you the formal definitions (you're just one search engine query away from it ...) and try to depict it in more approachable way ...
Heuristic 101
Hopefully you're familiar with Cynefin, so you know that non-trivial problems vary & not all of them can be tackled in the very same way. Some class of problems (so-called "complex" problems) do not have obvious solutions & are not easily splitable using "divide & conquer" method. Or - in some cases - the accurate solution would just take too much time / require too much effort to get done.
And now enter - heuristics.
This word's origin lies within the ancient Greek language & is supposed to mean "discovery" - which is not far by much from what heuristics do.
Heuristic is a technique of (supposedly) solving the problem in a simplified, limited, constrained, faster way so it (solving) is more practical & efficient (than complete, fully-fledged solution). We accept that the problem we've solved is a bit different (than it originally was) or there are some limitations & assumptions introduced, but these do not kill the overall purpose of the exercise - quite the contrary, heuristic provides the knowledge that would otherwise be too expensive or even out of our reach.
Yikes, that was supposed to be easy to clarify. No worries, it is.
Heuristics in the wild
Let's try the practical example:
There's a workforce of 100 people, working together in the same location. They are all contracted to work 8 hours per day, but their work hours are quite flexible - yes, they appear in the morning (in general) but not all in exactly the same time (+/- 1h). There's no time-tracking system and apparently some of them have started to abuse the rules, working shorter than specified in the contract. If that's true (for now it's a hypothesis), this has to finish. What to do?
Well, there are several ways of approaching that. One would be to install card terminals in all the exits, so we measure the time each individual spends in the office, but it's rather expensive & hereby not really practical. The other way would be to oblige some chosen individuals to check the attendance of their colleagues - that would not be really welcome as no-one wants to feel like a confident/informer.
But wait ... We don't need to know everyone's attendance (yet). We need to know whether the rule is being broken IN GENERAL (at all). That would already be a valuable piece of information (to determined whether we react at all). So why don't we try a heuristic:
- we observe that an average time the office starts to get crowded is around 9:30
- so we calculate how many people are there precisely at 9:30 (by simple Gemba walk) - I mean literally a single number, it's not important WHO is there
- then we do the same 8 hours later, at 17:30
What did we learn that way?
Well, if we assume (we can do it - it's heuristic, not an exact solution!) that:
- people who come EARLIER than 9:30 work honestly (8 hours)
- people who leave AFTER 17:30 work honestly (8 hours)
- AND these 2 groups of people are completely disjoint
then if we subtract number of people in these both groups from the number of all the people who were working in the office today, we get the number of rule abusers (MINIMAL - yet not exact - people who worked less than 8 hours on that day).
If we repeat this experiment e.g. 3 times in a short period of time, we probably learn something. But what?
- IF the difference (result of subtraction) is consistently higher than zero, we have a workplace culture problem - people DO abuse the rule (but we don't know how many of them exactly)
- but if the difference is either not consistent OR is zero it doesn't mean that the problem doesn't exist - it just means that our simplified solution was not smart enough to confirm it
See? This is a heuristic (& its applicability) in practice. The solution is far from being complete, it won't work in all the conditions, in some cases it won't provide the answer, but what we're gaining is:
- additional knowledge (that may be combined with results of other heuristics) that may be collected very quickly & easily
- and if certain criteria are met, the answer we get is reliable (enough)
Everyday heuristics
This particular heuristic is suited for one particular category of a problem - there was an issue & we came up with one-shot proposal of solution, fit for this specific case.
To be honest, majority of heuristics I use on the daily basis are quite different - they are best practices, patterns & techniques I've shaped up during all the years of my professional activity (so they are based on my own experience) that do provide certain (unquestionable by myself) benefits, e.g.:
- each new entity I create is classified clearly as belonging to a particular category of entities (I've built a closed list of those), e.g. inventory (repository that collects entities of the same type), append-only log (immutable collection you can only add to), process (piece of information that has value only within the time-frame of its lifespan), etc.
- all the children, grand-, grand-grand-, ... and further descendants within designed aggregate keep identity of ALL their ancestors (up to the root)
- nothing is ever deleted, stuff can only get marked as deleted - full coherence and auditability must also be maintained historically
These are examples of my "everyday-heuristics" - each of them has a particular person & is aimed to prevent a certain negative effect from happening. They are not "reusable components" - more like carefully chosen enriching properties of whatever's being crafted. And they are the crucial part of my repertoire.
Heuristics are one of the most powerful tools in every problem-solver's toolbox. They just have to be applied with pragmatism in mind. You really need to know WHAT you can sacrifice in solving the problem: is it accuracy? completeness? quality of solution (does it have to be optimal)?
Isn't heuristic just another name for a "short-cut"? Hell it is, but it's a very educated & smart short-cut that consciously balance value gained with cost of following the short-cut (accepted imperfections of the solution).
