The Hidden Cost Of Efficiency

-
resiliency is inversely proportional to efficiency
When it comes to coding, we developers take pride in writing programs that run fast and aren't bloated. Taken to the extreme, the cost would be readability, scalability, and maintainability.

We also take pride in writing software that is robust. Programs that recover gracefully when the unexpected happens are not just ideal, but real world requirements. Add security and privacy, and the cost here would be extensive testing, longer periods between roll outs, and a hit to performance.

This tension between efficiency and robustness is something developers wrestle with all the time, and a popular saying among programmers (and engineers) is  "Good, fast, or cheap. Pick two."¹

The impact of Covid-19 has prompted a bit of soul searching regarding efficiency and resiliency in the economy, supply chains, and manufacturing. Evidently, the world has tilted too far toward efficiency, and now finds itself vulnerable to shocks.

For example, Will Oremus explains on Medium that there really is a toilet paper shortage. It's not that manufacturing has slowed or that we're using more. The problem is that separate supply chains feed the commercial space and the consumer space, and that demand in the consumer space has dramatically increased as more and more of us work from home.

Willy Shih writes in Forbes that China has optimized electronics manufacturing with a large, low cost, and flexible work force, to the point of making it difficult for companies like Apple to establish alternate supply chains in other countries, including domestic production.

Bringing us back to programming, Moshe Y. Vardi ponders in ACM what Covid-19 teaches us about computing. While fault tolerance has been part of our discipline for decades, our frictionless sharing on social media has led to "filter bubbles, fake news, and extreme content."

Perhaps a little friction, a bit of inefficiency, a sprinkling of built-in costs, are good things... vital even. Banned from our vocabulary ought to be just-in-time inventory, friction-free economy, and a perfect informationally efficient market.


¹ Street food comes closest to picking all three, but that's a subject for a foodie blog.

Comments

Post a Comment

Popular posts from this blog

MR2 Check Engine

-
Image
Shown here is the 1991 Toyota MR2. Thanks to the mechanical skills of a family enthusiast, it purrs, growls, and turbo whistles like a dream.   My hardware ability doesn't go much further than oil changes. Rather, my expertise is in software, and I wrote an Android App (iOS version is in progress) to diagnose the flashes of the check engine light. This second generation MR2 predates the OBD2 connector, a standard used to diagnose engine, transmission, and emissions problems quickly and easily. Instead, we have a flashing check engine light which needs some deciphering, followed by a lookup in the service manual. Basically, you count flashes to arrive at fault code number. A short pause (~1.5 seconds) indicates the start of the next digit. A medium pause (~2.5 seconds) indicates start of the next fault code. And a long pause (~4.5 seconds) means the sequence has ended and will repeat. The video below corresponds to the codes 41 and 51. Using the the MR2 Check app and selecting the 3
Read more

Bookshelf: UNIX A History and a Memoir

-
Image
  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
Read more

Bookshelf Classic: The C Programming Language

-
Image
My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
Read more