Technology Evolution Spiral: The Engineer’s Perspective.

I graduated from college 25 years ago: a millennium in programmer career, as our technology changes every six months. Even back then, at the dawn of Internet, my professors stressed the importance of learning to learn instead of cramming specific textbooks and seemingly “fundamental” algorithms. The few smartest professors that is, in my humble opinion. The majority made a living teaching those “fundamentals” w/o thinking too much about anything outside their memorized books.

The reason I brought this up, is to clarify who I am: an engineer. My mind works differently from the scientist’s one, let alone the teacher’s (of no doubt highly scientific things). Scientists research, focusing on the new. They carefully check the work of other scientists to avoid plagiarism, unthinkable in those circles. Teachers, on the other hand, know everything about the past and present technology. And engineers… this is where it gets interesting, particularly if one is applying to an engineering position at Google or Amazon (sorry, couldn’t resist). Unless things changed recently, and sorry again for stereotyping, their infamous “algorithmic” interviews are far from urban legends. Google apparently views itself as an extension of MIT’s research wing, while Amazon has a strong affinity for MIT auditoriums devoted to education.

Engineers build. We focus on the result — the flawless machine; instead of winning the race to publish a groundbreaking scientific discovery. In the ideal world and less dynamic fields like civic engineering most of the school-taught fundamentals works as is — typically not even used directly, as one builds from prefabricated and fully tested blocks/modules e.g. libraries implementing those “fundamental” algorithms. I wish I could always rely on textbooks and manuals in my everyday work. The real-world complexity of consumer behavior, social interactions, and business processes requires composing the prefabricated blocks in a very unusual manner, let alone fabricating your own if you cannot find the right piece to complete the puzzle. There are also multiple choices in between: tweaking existing pieces, splitting them, gluing together, etc.

At the end of the day we compose the final product from what’s available; by the book or in a completely new way doesn’t matter. We build from blocks and materials that exist, which is a complete opposite of writing a dissertation on things that don’t yet exist. We don’t care if something’s been already invented. We can even “invent” it anew on the fly, working under an aggressive deadline to release the product, with no time to check if some technology existed before in a slightly different form, not applicable to the task at hand. The only thing, that matters is the finished product.

We focus on building that product, and often it’s faster to make some easy mini-invention instead of scanning books for ideas. Or worse, memorizing them in a college exam manner. The human brain has limited memory capacity. One can either turn it into a library, where he/she can quickly find the book with the right scene/quote. Or you can turn it into a neat machine shop, placing various tools within reach and constantly updating your tool set depending on the project and task at hand. It’s either one or another. A library is a poor place for machining.

Thus, the concept of technology spiral comes naturally to us, engineers, whether both scientists and teachers may struggle with it a little. That spiral is best visualized as a coil spring. Place it vertically and draw a longitudinal line pointing up: the way of progress. As you traverse the spring, the coil returns to exactly the same spot on the horizontal plane axis, which represents a specific evolving technology e.g. external (tractor/horse) or internal (built-in engine) means of vehicle propulsion (see the example below). That circular motion is a perfect model of the eternally repeating tech evolution process: moving away from some “old” invention at first and inevitably revisiting it later, only that time at a much higher level.

The 19th Century horse carriage vs. Skywalker’s pod racer seems like a corny comparison. I chose it because I love driving cars and motorcycles. The majority of the population hates driving and views a car exactly like aristocrats viewed their luxurious carriages 150 years ago: as a room on wheels — living room, office, or even bedroom doesn’t matter. It is one’s personal space, isn’t it? Especially nowadays, packed with gadgets everyone likes to setup his/her own way. You want everything clean and customized to your liking, when e.g. you rent a car, someone just used before you. Here’s a unicorn idea for you: can we own the “room” and rent the “wheels”: drivetrain, etc. plus the engine instead of renting the whole car — like travelers changed horses in the past? The cabin (room) doesn’t wear as fast or require constant maintenance compared to the car’s mechanical components.

You’ll be hard-pressed to find a true computer invention nowadays — in a Nobel prize winning scientific sense. Everything has been invented in one form or another. Did Larry Page and Sergey Brin invent Internet search? Did Mark Zuckerberg invent a social network? Did Steve Jobs invent a touchscreen mobile phone? TikTok? Instagram? I can go on for 10 pages. All of those products and services are results of brilliant engineering: building from the pieces that already existed in a very non-orthodox way, vastly improving products and technologies invented before. Technology spiral in action.

So, do I care about the academic/historic accuracy of a single taken out of context statement? E.g. if ancient IBMs already ran w/o hard drives when I talk about the RAM-only future of computing? It doesn’t matter if the computer has such drives or not. It matters what you use the new in-memory architecture for i.e. the finished product. Like the digital copy of a human brain.

Everyone knows how Mad Men era computers functioned w/o disk or tape drives. One loaded his/her program via punch cards, prompting the computer to enqueue/run it, then picked up the result from a noisy typewriter-style printer an hour later. Could one write a moderately complex object-oriented (event-based, interactive, etc.) system to control e.g. the light switches of a single room in a “smart house”? How about a single semi-intelligent coffee maker? Would have taken lots of punch cards back then. Wait, C++ wasn’t invented yet. And yes, I’m aware there are/were other, academically “better” OO languages, so spare me this and other out of context pet peeves. Know any robust commercial OO code written in those languages in 1978?

It’s a bit silly to bring even the greatest of books to a noisy machine shop. Indulge in such re-reading in a quiet library of an academic shrine, and let us, machinists, do our job.