Negative Knowledge in Engineering

One of the most powerful principles laid out in the 2007 book Black Swan (author Nassim Taleb) is that “negative information” is more reliable than positive information. An example of negative information could be a flaw in a financial model, whereas the principles in the financial model all constitute positive knowledge.

Descriptive Versus Prescriptive Problems

Science, perhaps more than any other field, runs on negative knowledge. It has taken centuries of progress for us to fully accept that no theory can ever be proven fully no matter how much evidence there is in favor of it, while a single piece of evidence can entirely dethrone the theory. Experience from participation in financial markets can mirror the process seen in science. Both financial trading and scientific inquiry suffer from the same ailments that come from attempting a descriptive model of something partially (or almost completely) unknown.

Aside from scientific inquiry, my gut reaction to the value of negative information is “so what?” For someone managing a financial asset, there is no true null-option. For cases in business, the null option might not necessarily require less work than the other options. Assets have to exist somewhere so the question of asset allocation is always comparative. Taleb takes the notion of negative knowledge to a sensationalist extreme, asserting that a good deal of positive information is less than worthless, in that decisions informed by the knowledge actually have a lower expected return than those ignorant of it. An absurdist piece of trading advice would, thus, be to gain knowledge from the traditional experts and then take the opposite action of what it suggests.

For science, you may be able to apply similarly absurd statements in limited subsets of bleeding-edge research. Fields exists which are almost entirely null-result fields, like medical research, where the lack of true triple-blind controls on publications would probably force the aggregate of published knowledge into the “less than worthless” category, if those results are weighted by the number of articles published in peer-reviewed journals.

Myself, I’m more interested in a modified version of the “negative information” hypothesis that can be applied to engineering, and more broadly a theory of action that is compatible with building large comlex projects.

Building Things is Hard

Building and maintaining a complex infrastructure project can be called both a serial process, and a defensive action. The notion of “correctness” is predicated on getting many things right, with a low tolerance for failure — not just among the component problems, but for the project as a whole.

Additionally, the payout profile consists of mostly modest returns punctuated by rare and severe negative events. Only by consistent and frequent operations are the negatives outweighed by the positives.

This sets up a fascinating contradiction between the risk/payout profiles of engineering megaprojects and typical business sense. Both socially and professionally, the least risk-adverse tend to be more successful. Fail-forward attitudes and cultures are the most fruitful on the long-term. Thus, the Zipf–Mandelbrot distribution referenced in Black Swan is the exact opposite of what we see for large engineering operations. This distribution describes a distribution of modest values with a few extremely positive outcomes. Some have even gone so-far as to claim that the productivity of employees may be described by the distribution.

At this point, it’s simply interesting to note that the payout profile of engineering operations seems to be strangely the reverse of the profile we should expect in terms of productivity of individual engineers.

Disproof as the Contribution Model — Collectivization of the System

My biggest takeaway is that individuals are fully incapable of either producing or operating any engineering project big enough to be relevant in today’s world. Software Engineers are only able to give the appearance of doing so by use of a growing library of globally available software that they build on top of, invariably adding less complexity than what the libraries came equipped with to begin with.

Financial markets are an increasingly important analog to fields of engineering because of these realities. A modern financial market contains pricing information that can be very-well considered an engineering product without any engineer intentionally creating it. There is a high degree of dimensionality in the pricing data, and it needs constant nurturing to keep it running smoothly. The market valuations are the very thing that Soviet era thinkers dreamed could be engineered, published, and then carried out in 5-year plans in a top-down control structure. But what separates this from other engineering projects? Why have the solutions to some problems been collectivized but not others?

The answer to that question might be that enough time hasn’t passed yet. The scale and sophistication of our global means of production have been monotonically increasing, and with that, our ability to decentralize challenging problems grows and the need to do so also intensifies. As the problems grow more complex, it starts to become less reasonable to have an individual person design a part of it, and more reasonable to have individuals chip away at parts of it. In short, engineering problems are becoming collectivized, and the contribution model focuses on improving the system by attacking the merit of small constituent parts, leading to improvements.

The gap remains in measurement. Quality control is a problem, because a negative change to a collectivized system can’t be evaluated except for at a high cost. Collectivization of large projects, as I described above, constitutes a method of solving the reverse of a known evaluation method. It is analogous to mathematical root finding or solving the adjunct form of an equation. The barriers to employment of this type of model are largely in the evaluation system. It’s hard to resolve a value difference between the system before a change, and after the change, and its even hard to try to quantify it exactly. Because of that, an institutionalized system for maintaining a large project can not how to appropriately respond to contributions, and this task boils down to individual’s discretion and dedication to the tasks of moderation, curation, and management, which brings us back to scaling constraints similar to what megaprojects already suffered with. This is, however, only a problem in the extreme where the collectivized system is not bullet-ridden with flaws, as most closed systems would be if they were opened up to public scrutiny.

Obligatory analytical writing, online participation account for Medium. Engineering, software, books, space, constant daydreaming.

Obligatory analytical writing, online participation account for Medium. Engineering, software, books, space, constant daydreaming.