The IT Industry Is a Disaster

  1. The industry settled on a computer architecture that is fundamentally flawed: the Von Neumann architecture: a design in which a computer is controlled by a sequence of steps; yet, real world devices like phones, TVs, cars, and so on are not a good fit for that, because they handle real time events, and so Von Neumann programs are susceptible to “race conditions”, aka “time of check, time of use” (TOCTOU) programming errors, unless the programmer knows how to write “real time programs” — which very few do.
  2. Today’s computing industry is driven by features, and “coders” who can rapidly produce features. The culture of engineering has left the programming industry. Thus, while for example there used to be a professional category called “real time programmer”, there is no longer — there are only “coders” — as if knowing how to code is the same as knowing how to design and implement a reliable software controlled system: it is not.
  3. The industry does not have robust mechanisms for ensuring that core technologies and protocols are well designed. Thus, we end up with abominations such as HTTP, which is arguably the worst protocol design in history, and our entire Web infrastructure rests on it. The same can be said for Javascript; put together, Javascript and HTTP have created an unfixable foundation that commits the Web to forever being insecure and brittle.

TOCTOU — the Bane of Von Neumann

Probably the most pervasive and reliability-destroying type of error in software today is the TOCTOU error, aka “race condition”. It goes like the following pseudocode:

  1. Check if something you need, say network or file A, is available.
    a. If it is, then start using it;
    b. Else, do something else.

Standards Through Popularity

The fact that the entire computing industry is hobbled by a bad choice of architecture is bad enough, but the industry is also rudderless and suffers from mob rule.

How can we fix this?

We can’t. Things are too far gone. However, things could be made a-lot better. For one, we need to make programmers (or their employers as the case may be) liable for losses that result from security bugs and other bugs. That is the only way that individuals and companies who write software will start to pay attention to how reliable their product is. It is the only way.

Who Am I?

Why should you believe me? What do I know about this? Be your own judge, but here’s my background: I was on the team at Intermetrics that created VHDL, the real time programming language that is widely used today for designing chips and systems. I wrote the first simulation program using VHDL, and I wrote the first behavioral synthesis silicon compiler for VHDL, back during the late 1980s while at CAD Language Systems. After that I co-founded a company that built a great number of enterprise systems using Java and Solaris server technology, and wrote Sun Microsystem’s Enterprise Java book. Since then I have consulted to help companies figure out why their applications are unreliable, and collaborated with Peter Neumann on a book about application security and reliability. In recent years I have focused on DevOps and DevSecOps. I am a developer — not a check-the-boxes control person. I work with teams to help them code better, but I also understand what does not work, and I see a-lot of it.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store