In 1896, at the University of Lausanne in Switzerland, a young economist by the name of Vilfredo Pareto published a paper showing how 80% of the land in Italy was owned by 20% of the population. Fast-forward to 1941, when a management consultant named Joseph Moses Juran found Pareto’s paper and began applying it to quality control issues, postulating that 80% of the problem is attributable to only 20% of the causes.
Others began to notice that this principle Juran had found, the Pareto Principle, applied to things that they were working on–in manufacturing, most defects are the result of a small percentage of the causes of all defects. In business, 20% of a team’s members are going to make up 80% of a project’s successful results. And 20% of a businesses’ customers will create 80% of the profit.
By understanding the Pareto Principle, you can begin to identify areas in your field where a small amount of attention will go a long way.
For myself, as a programmer, this principle comes into play in several different areas. The most obvious is that 80% of logic of a program can be done with 20% of the effort; conversely, the last 20% of the logic requires 80% of the effort. In any program that I work on, I can always get out the basic logic in no time–write a script to login to a webservice, no problem; turn that script into a finished product for our end users, that could be weeks, even months of work.
This also applies to how you debug and optimize a program. 80% of the bugs you will see are caused by 20% of the code you write.
def buggy(): '''Some buggy function''' return 1/0 if __name__ == '__main__': # Do a lot of setup and define some variable. # call our buggy function buggy()
Note that in the above code snippet, while purposefully bad, the only problem is in the
buggy function we wrote. There was nothing wrong, for example purposes, with the rest of the code. 20% of code causes 80% of our headaches.
It is a general rule of thumb via the Pareto Principle that your program will spend 80% of its time in 20% of the program. This leads to an easy way to optimize your program if hardware allows it: optimize the 20% of the program where your code does 80% of its work to get the fastest return on your efforts.
For an analyst working in Open Source Intelligence, the application of the Pareto Principle can help to identify where in your investigation you can apply concentrated effort to yield more results and where you need to apply more effort to round out the information you have gathered.
In general, 80% of your time will be gathering the first 20% of the information on your target. This is the time you spend gathering your initial data points: names, aliases, email addresses, etc. The last 20% of your time is spent building up the remaining 80% of your investigation: grabbing social media profiles, building out friend networks, jobs, workplace proximity associates, etc.
The Pareto Principle has many applications beyond economics and manufacturing. In the OSINT world, 80% of the value is found in 20% of the results; likewise, 20% of your effort will derive 80% of your value. Having this in mind during the planning phase of your investigation can help you understand how your investigation will play out.