Regardless if he ever measured it or not, he did capture an important aspect of complicated problem solving - problems have many axis. Each perspective by itself only explores part of the problem axis, and any additional perspective explores more axis, en-route towards a comprehensive solution.
This is where the power of TDD (test driven development) and FP (functional programming) comes from.
When you do TDD, you explore axis which do not directly target the question of "how do I solve the problem", but rather the question "How to detect a wrong solution". By following these axis, alongside with exploring the regular problem solving mechanisms (as we try to change perspective, not just use one different perspective), the chances of reaching a more comprehensive solution are increased. The side-effect of this approach is having the tests later on to allow ongoing verification of the consistent behaviour of the software.
When you do FP, you explore axis which do target the question of "how do I solve the problem", but via different axis (as the industry standard is doing it the OO way). This means different model of the problem, different abstractions, different computation mechanisms. Again, by exploring additional routes to solve the problem (this time they target the question directly), you increase your chances of finding a comprehensive solution to the problem. The side-effect of using this approach is a larger set of simply solvable problems, as there are problems that are entry-level on the FP axis, while being advanced when projected onto the OO axis (and one of the benefits of simple solutions is that they are very easy to test).
In the same way that novelists are not in the business of books writing, but rather in the business of story telling deployed via books, software engineers are not in the business of writing software, but rather in the business of problem solving deployed via software . This is why using the extra perspective(s) is so important.