Not “Supply and Demand?”
The supply and demand equilibrium is elementary economics, and easy to explain to anyone who understands graphs. The demand curve has quantity intercept the number of units that could be given away, and price intercept the cost at which no sales will happen. The supply curve has both intercepts at the origin, and a positive slope–theoretically, as the selling price increases, so does willingness to produce, and indefinitely so. Of course there are other constraints such as factory floor space and trained personnel to produce the goods, but the only real limit to sales is customer demand. The sweet spot where the two curves intersect is roughly market equilibrium. “Roughly” because other factors such as taxation, government regulations and social constraints, shift the curves around.
One of the game changing aspects of the early years of the information age has been the revolution in supply chain management. Pioneered by retail giants such as Walmart and Canadian Tire, the premise is simple: stock shelves to meet a few days’ projected demand, use computerized point-of-sale software to track inventory and place nightly orders to restock shelves on a daily basis. Use at most one warehouse for all the stores in the region, but have shipments made direct from the manufacturer whenever possible. Plan for appropriate stock months prior to projected sales and have orders in the chain for seasonal goods well ahead of time to ensure that inventory is always relevant and robust, and that stock dries up only when demand ceases.
Tim Cook is the quintessential modern master of the art of supply chain optimization, and rose to prominence at Apple precisely for that reason. Computerized, up-to-the-minute sales, inventory, and supply information is the key to keeping warehouse space, costs, and therefore prices all as low as possible–essential to keep a disposable, consumer-oriented profligate waster society ticking along at peak consumption. Restaurants do exactly the same thing in the same way. After all they too are in the manufacturing business–they make meals, and have their own supply chains to optimize–critical in the food business, where ingredients must be both fresh, and sufficient for the days’ customers with minimal wastage at closing time.
In effect, supply chain managers are engineers. They must be detail-oriented planners know the business intimately, have a systematic, crystal clear statistical understanding of exactly how product is created from the input of parts (ingredients) through the flow of manufacture to the output of finished items. They have to be capable of reaching back along the chain to the makers of parts, and forward to the retail side, finding ways to shorten both ends of the chain, minimizing warehousing of both parts and finished product, and moving quickly and decisively to respond to alterations in market conditions–ideally well ahead of changes in actual demand at the cash register. Ideally, (and necessarily in the restaurant business) the day’s manufacturing is exactly covered by the same day arrival supply of part, and the day’s production is moved off the premises into the retail chain by day’s end, perhaps by relocating the same rail cars that brought parts in the morning over to the other end of the factory and re-loading them with product in the evening.
The Spy commented on such matters in early eighties’ columns and discussed the matter at greater length in his text The Fourth Civilization–Ethics, Society, and Technology which he is currently revising for a fifth edition, along the way putting numerous predictions of previous editions into the past tense. Supply chain optimization was the way of the future then, and is the way of the present now. Many who failed to implement it are long gone from the scene.
But there is more to engineering
than planning and optimization, for good old Murph needs to be taken into consideration. Putative software engineers’ second set of lessons after the basics (sequence, selection, repetition, composition and parallelism) have been drummed in (don’t say “mastered” for a few more years) are all about prioritizing writing fail-safe code. Class, ask yourself what your program will do when (not if) everything goes horribly, terribly wrong–because it will, and at the worst possible time, in the most vulnerable part of the code that is the most expensive to fix, and in a manner that causes the most possible inconvenience and expense to the customer, and generates the largest possible lawyer’s’ bills to defend the ensuing malpractice lawsuits. Yes, yes, it’s not called malpractice yet, but the professionalization of software development is only a matter of time, the time it takes for it to dawn on people that software should not have enterprise-destroying bugs any more than should manufacturing equipment.
Bullet proofing code is itself a discipline, and not to be taken lightly. This, by the way is the real purpose of exceptions and their handlers being in a programming language–they are not there to create lazy GOTO statements, but to fix those problems you thought could not happen, but provided for because your gut knew they would anyway. To put it bluntly, software should never crash and burn or lose or corrupt when everything goes wrong anyway.
You do your customer research to know exactly what is needed and how it is to function, you plan and develop the software top down, you build and show prototypes to find out what the customer really wanted or needed (usually not the same as what was originally articulated) and then write your code with failsafes–pre and post conditions for subroutines, modularity to prevent unwanted side-effects, testing inputs to ensure they meet preconditions for handling, redundant data backups, clear documentation, informative error messages, and so on. You test it to death both with automated cases and human operators, release a beta version for customers to try, revise again, and only put it into production when it has survived exhaustive scrutiny, then train on and support it like a fanatic. Not elementary, but middle school. Most consumers have not awoken yet to the fact that it is indeed possible to write good software that actually works; rather, there is a general belief, reinforced by the numerous bugs we all work around, that the task is too hard, and that malfunctioning, bug-ridden, data corrupting software is impossible to write and must be accepted. Not so.
Why then, is it tolerated in the marketplace when the way to apply sound engineering principles to software development has been well known for decades? Mostly because of the rush to market causes companies to impose artificial deadlines and rush development to maximize profit, rather than go slow and do it right. The Spy’s students graduate with the knowledge of how to do it right, but because they start at the bottom of the pecking order, have no influence on procedural matters, and only a few companies, most notably Apple again) have a culture of getting software right, and even they make mistreaks. Not so the Spy, of coarse.
The operating principle is a form of redundancy
namely that when one piece of code fails, something else takes over to ameliorate the situation. Input data in the wrong format? Tell the user and ask for re-entry. Two processes in deadly embrace? Time one out after a few milliseconds of frozen time, release its resources, and go on a wait queue until all the resources needed signal availability. Better yet, do that first, before trying to run. Data type value overflow? What is the recovery plan? Errors in the data file? Check the backup (there is one of course) and if it is corrupt and there is no scrubbing routine to fix it, inform management rather than going ahead the processing and making things worse. The program has, despite all your failsafes, catastrophically failed anyway? You did write code to execute during termination to at least flush buffers to physical files, didn’t you? The point is, there are well-known ways; these are just a few simple examples.
What is the connection
between supply chains and software development? Glad you both asked. It’s the necessary engineering mindset–plan for what happens when everything goes horribly terribly wrong, so the damage is contained. You see, highly optimized supply chains are fantastic money and waste savers when they work as they are supposed to, but when anything fast and efficient goes wrong, it also does so quickly and efficiently, becoming a major catastrophe almost before you know it. Ahem.
– What was the backup plan automakers had for a failure in the chip supply chain? It turned out to be curtail production and lay off workers. Apple seemed to be able to keep going without interruption, at least for a time. Were the cars engineered, but their manufacturing supply chain not?
– What was the backup plan for getting food out of Ukraine when the Russian dictator decided to steal a large fraction of the country and occupied or mined its grain ports?
– What was the backup plan when giant Canadian telecom provider Rogers decided to upgrade its core network software in the summer of 2022, and a bug caused an electronic typhoon that disabled its main routers, brought down the company’s entire network, and with it Canada’s government systems, and most of the nation’s retail credit card network, as well as shutting out millions of customers from the Internet? Seriously? They did this on the operating network’s live controllers rather than on a test bed backup? They had no fail-over system either to spare controllers, or to redirect traffic to Bell and Telus? You gotta be kidding. The Spy would fail a student project that operated that way.
– What is the backup plan for data theft, DOS or ransomware attacks in corporations, banks, government, the military? How is it even possible to hold a major entity’s data for ransom? Have they never heard of backups?
– Why does Apple obsolete its products only five years after replacing them with something supposedly more better gooder? To make more money of course, but what is an owner’s backup plan when Apple (and others) stop supporting a product?
– Ditto cryptocurrency exchanges. How is it possible to devise a system where money can be stolen, sometimes in the hundreds of millions, and there’s no audit train to make it retrievable?
– And, what is the backup plan for when large areas of the planet become uninhabitable due to climate change causing desertification in some areas and catastrophic weather events in others due to rising temperatures, or flooding of many low-lying heavily populated areas in others?
– What, moreover, is the backup plan for the next pandemic? for the next famine? or the next aggressive war by Russia or China? for a potential collapse of the world economy?
Do we ever learn anything, or do we just doom ourselves to repeating a history of failures?
During a recent ferry trip
the Spy could not help by hear a loud recital of a young lady’s emergency kit contents. If he recalls correctly it included such items as a comb, makeup remover, aspirins, perhaps a little money, and assorted other odds and ends to cover little setbacks–not a bad idea. World leaders of enterprises and countries take note. But, as he passed the group on his way to the car deck, he remarked “You missed something for that emergency kit. You need to put in a memory stick to back up your files. He regrets that he did not also mention she should add least one Bible to her reader.
The Spy uses both Time Machine and Carbon Copy Cloner to make hourly, daily, weekly, and monthly backups of his files partitions both at home and the office (54K files occupying about 30G, not counting archived lecture recordings stored elsewhere). He also backs up his home files to a partition on an SSD to take to work in the morning and restore there, and he backs that up to a different partition to take home and restore there at the end of the working day. He doesn’t very often lose data, but cannot say “never”. He also has both the Olive Tree and Logos Bibles and study materials on all his devices, BTW.
What is the bottom line?
In summary, the Spy proposes a new law, the first in a decade for this column, and somewhat related to the fifth (The Law of Large Projects and its “Planning to Fail Corollaries”):
The Spy’s twelfth Law: Planning for catastrophe
It’s not just that failure to plan is planning to fail, it’s also that failure to plan for failure is planning for catastrophe.
Meanwhile,
back at the ranch, the Spy himself is recovering from a cold (not COVID, seven negative tests) bad enough to cause him to miss two weeks of work, the first time he’s been ill enough to stay home from work in forty-eight years–and that previous time was because he had mononucleosis, not for the usual six weeks, but for twenty-two months, and took many years to recover healthy sleeping patters afterwards. Ah, well, back to work today, a few days vacation time at the end of the week, then full on press to get ready for the fall influx of eager new students who are still in high school mode and have to learn how to manage their own education instead of having it done for them. Looking forward to that first year discrete Math course–all the really interesting mathematics that is not Calculus, but the first time students have encountered logic. It’s remarkable how few people, even respected leaders, have any idea what that is. What do they teach them in the schools these days? His other course uses the Fourth Civilization text mentioned earlier. Gotta get that draft of the fifth edition done for them–what’s on the web site is sadly out of date. TTFN.
–The Northern Spy
Opinions expressed here are entirely the author's own, and no endorsement is implied by any community or organization to which he may be attached. Rick Sutcliffe, (a.k.a. The Northern Spy) is professor of Computing Science and Mathematics and Assistant Dean of Science at Canada's Trinity Western University. He completed his fifty-second year as a high school and university teacher in 2022. He has been involved as a member of or consultant with the boards of several organizations, and participated in developing industry standards at the national and international level. He was co-author of the Modula-2 programming language R10 dialect. He is a long time technology author and has written two textbooks and ten alternate history SF novels, one named best ePublished SF novel for 2003. His various columns have appeared in numerous magazines and newspapers (dead tree and online formats), since the early 1980s, and he's been a regular speaker at churches, schools, academic meetings, and conferences. He and his wife Joyce celebrated their fiftieth anniversary in 2019 and lived in the Aldergrove/Bradner area of B.C. from 1972 to 2021, where he now continues alone, depending heavily on family to manage.
URLs for Rick Sutcliffe’s Arjay Enterprises:
- The Northern Spy Home Page: http://www.TheNorthernSpy.com
- opundo : http://opundo.com
- Sheaves Christian Resources : http://sheaves.org
- WebNameHost : http://www.WebNameHost.net
- WebNameSource : http://www.WebNameSource.net
- nameman : http://nameman.net
General URLs for Rick Sutcliffe’s Books:
- Author Site: http://www.arjay.ca
- Publisher’s Site: http://www.writers-exchange.com/Richard-Sutcliffe.html
- The Fourth Civilization–Ethics, Society, and Technology (4th 2003 ed. ): http://www.arjay.bc.ca/EthTech/Text/index.html
Other URLs of relevant interest:
- BC Government COVID site: http://www.bccdc.ca/health-info/diseases-conditions/covid-19
- TWU COVID Info: https://www.twu.ca/covid-19-information
URLs for items mentioned this month:
- Olive Tree Bible Study Apps: https://www.olivetree.com
- Faithlife: Maker of Logos: https://www.logos.com
- The Spy’s Laws: https://www.thenorthernspy.com/spyslaws.htm
