Agile Project Management at SpaceX

In Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework, I explained that back in the 1950s and 1960s IT professionals used an Agile methodology to develop software because programs had to be very small to fit into the puny amount of memory that mainframe computers had at the time. Recall that the original UNIVAC I came out in 1951 with only 12 KB of memory. By 1970, mainframe computers typically only had about 1 MB of memory that was divided up into a number of fixed regions by the IBM 360-MFT operating system. Typically, the largest memory region was only 256 KB. Now you really cannot do a lot of logic in 256 KB of memory so applications in the 1960s consisted of lots of very small programs in a JCL job stream that used many tapes for input and output. Each step in the job stream had a very small program that would read the tapes from the previous job step, do some processing on the data, and then write out the processed data to tapes for the next step in the JCL job stream. The output tapes were then used as input for the next step in the JCL job stream. For more on tape processing see: An IT Perspective on the Origin of Chromatin, Chromosomes and Cancer.

So this kind of tape batch processing easily lent itself to the prototyping of the little programs in each job step. Developers would simply "breadboard" each little step by trial and error like they used to do on the Unit Record Processing machines of the 1950s that were programmed by physically rewiring the plugboards of each Unit Record Processing machine in a job stream. The Unit Record Processing machines would then process hundreds of punch cards per minute by routing the punch cards from machine to machine in processing streams.

Figure 1 – In the 1950s, Unit Record Processing machines like this card sorter were programmed by physically rewiring a plugboard.

Figure 2 – The plugboard for a Unit Record Processing machine. Programming a plugboard was a trial and error process that had to be done in an Agile manner. This Agile programming technique carried over to the programming of the small batch programs in a tape batch processing stream.

To get a better appreciation for how these small programs in a long tape batch processing stream worked, and how they were developed in a piecemeal prototyping manner, let's further explore tape batch processing.

Batch Tape Processing and Sequential Access Methods
One of the simplest and oldest sequential access methods is called QSAM - Queued Sequential Access Method:

Queued Sequential Access Method
http://en.wikipedia.org/wiki/Queued_Sequential_Access_Method

I did a lot of magnetic tape processing in the 1970s and early 1980s using QSAM. At the time we used 9 track tapes that were 1/2 inch wide and 2400 feet long on a reel with a 10.5 inch diameter. The tape had 8 data tracks and one parity track across the 1/2 inch tape width. That way we could store one byte across the 8 1-bit data tracks in a frame, and we used the parity track to check for errors. We used odd parity, if the 8 bits on the 8 data tracks in a frame added up to an even number of 1s, we put a 1 in the parity track to make the total number of 1s an odd number. If the 8 bits added up to an odd number of 1s, we put a 0 in the parity track to keep the total number of 1s an odd number. Originally, 9 track tapes had a density of 1600 bytes/inch of tape, with a data transfer rate of 15,000 bytes/second. Remember, a byte is 8 bits and can store one character, like the letter “A” which we encode in the ASCII code set as A = “01000001”.

Figure 3 – A 1/2 inch wide 9 track magnetic tape on a 2400-foot reel with a diameter of 10.5 inches

Figure 4 – 9 track magnetic tape had 8 data tracks and one parity track using odd parity which allowed for the detection of bad bytes with parity errors on the tape.

Later, 6250 bytes/inch tape drives became available, and I will use that density for the calculations that follow. Now suppose you had 10 million customers and the current account balance for each customer was stored on an 80-byte customer record. A record was like a row in a spreadsheet. The first field of the record was usually a CustomerID field that contained a unique customer ID like a social security number and was essentially the equivalent of a promoter region on the front end of a gene in DNA. The remainder of the 80-byte customer record contained fields for the customer’s name and billing address, along with the customer’s current account information. Between each block of data on the tape, there was a 0.5 inch gap of “junk” tape. This “junk” tape allowed for the acceleration and deceleration of the tape reel as it spun past the read/write head of a tape drive and perhaps occasionally reversed direction. Since an 80-byte record only came to 80/6250 = 0.0128 inches of tape, which is quite short compared to the overhead of the 0.5 inch gap of “junk” tape between records, it made sense to block many records together into a single block of data that could be read by the tape drive in a single I/O operation. For example, blocking 100 80-byte records increased the block size to 8000/6250 = 1.28 inches and between each 1.28 inch block of data on the tape, there was the 0.5 inch gap of “junk” tape. This greatly reduced the amount of wasted “junk” tape on a 2400-foot reel of tape. So each 100 record block of data took up a total of 1.78 inches of tape and we could get 16,180 blocks on a 2400-foot tape or the data for 1,618,000 customers per tape. So in order to store the account information for 10 million customers, you needed about 6 2400-foot reels of tape. That means each step in the batch processing stream would use 6 input tapes and 6 output tapes. The advantage of QSAM, over an earlier sequential access method known as BSAM, was that you could read and write an entire block of records at a time via an I/O buffer. In our example, a program could read one record at a time from an I/O buffer which contained the 100 records from a single block of data on the tape. When the I/O buffer was depleted of records, the next 100 records were read in from the next block of records on the tape. Similarly, programs could write one record at a time to the I/O buffer, and when the I/O buffer was filled with 100 records, the entire I/O buffer with 100 records in it was written as the next block of data on an output tape.

Figure 5 – Between each record, or block of records, on a magnetic tape, there was a 0.5 inch gap of “junk” tape. The “junk” tape allowed for the acceleration and deceleration of the tape reel as it spun past the read/write head on a tape drive. Since an 80-byte record only came to 80/6250 = 0.0128 inches, it made sense to block many records together into a single block that could be read by the tape drive in a single I/O operation. For example, blocking 100 80-byte records increased the block size to 8000/6250 = 1.28 inches, and between each 1.28 inch block of data on the tape, there was a 0.5 inch gap of “junk” tape for a total of 1.78 inches per block.

Figure 6 – Blocking records on tape allowed data to be stored more efficiently.

So it took 6 tapes to just store the rudimentary account data for 10 million customers. The problem was that each tape could only store 123 MB of data. Not too good, considering that today you can buy a 1 TB PC disk drive that can hold 8525 times as much data for about $100! Today, you could also store about 67 times as much data on a $7.00 8 GB thumb drive. So how could you find the data for a particular customer on 24,000 feet (2.72 miles) of tape? Well, you really could not do that reading one block of data at a time with the read/write head of a tape drive, so we processed data with batch jobs using lots of input and output tapes. Generally, we had a Master Customer File on 6 tapes and a large number of Transaction tapes with insert, update and delete records for customers. All the tapes were sorted by the CustomerID field, and our programs would read a Master tape and a Transaction tape at the same time and apply the inserts, updates and deletes on the Transaction tape to a new Master tape. So your batch job would read a Master and Transaction input tape at the same time and would then write to a single new Master output tape. These batch jobs would run for many hours, with lots of mounting and unmounting of dozens of tapes.

Figure 7 – The batch processing of 10 million customers took a lot of tapes and tape drives.

When developing batch job streams that used tapes, each little program in the job stream was prototyped first using a small amount of data on just one input and one output tape in a stepwise manner.

The Arrival of the Waterfall Methodology
This all changed in the late 1970s when interactive computing began to become a significant factor in the commercial software that corporate IT departments were generating. By then mainframe computers had much more memory than they had back in the 1960s, so interactive programs could be much larger than the small programs found within the individual job steps of a batch job stream. Since the interactive software had to be loaded into a computer all in one shot, and required some kind of a user interface that did things like checking the input data from an end-user, and also had to interact with the end-user in a dynamic manner, interactive programs were necessarily much larger than the small programs that were found in the individual job steps of a batch job stream. These factors caused corporate IT departments to move from the Agile prototyping methodologies of the 1960s and early 1970s to the Waterfall methodology of the 1980s, and so by the early 1980s prototyping software on the fly was considered to be an immature approach. Instead, corporate IT departments decided that a formal development process was needed, and they chose the Waterfall approach used by the construction and manufacturing industries to combat the high costs of making changes late in the development process. This was because in the early 1980s CPU costs were still exceedingly quite high so it made sense to create lots of upfront design documents before coding actually began to minimize the CPU costs involved with creating software. For example, in the early 1980s, if I had a $100,000 project, it was usually broken down as $25,000 for programming manpower costs, $25,000 for charges from IT Management and other departments in IT, and $50,000 for program compiles and test runs to develop the software. Because just running compiles and test runs of the software under development consumed about 50% of the costs of a development project, it made sense to adopt the Waterfall development model to minimize those costs.

Along Comes NASA
Now all during this time, NASA was trying to put people on the Moon and explore the Solar System. At first, NASA also adopted a more Agile approach to project management using a trial and error approach to solve the fundamental problems of rocketry. If you YouTube some of the early NASA launches from the late 1950s and early 1960s, you will see many rocket failures blowing up in a large fireball:

Early U.S. rocket and space launch failures and explosions
https://www.youtube.com/watch?v=13qeX98tAS8

This all changed when NASA started putting people on top of their rockets. Because the NASA rockets were getting much larger, more complicated and were now carrying live passengers, NASA switched from an Agile project management approach to a Waterfall project management approach run by the top-down command-and-control management style of corporate America in the 1960s:

NASA's Marshall Space Flight Center 1960s Orientation Film
https://www.youtube.com/watch?v=qPmJR3XSLjY

All during the 1960s and 1970s NASA then went on to perform numerous technological miracles using the Waterfall project management approach and the top-down command-and-control management style of corporate America in the 1960s.

SpaceX Responds with an Agile Approach to Exploring the Solar System
Despite the tremendous accomplishments of NASA over many decades, speed to market was never one of NASA's strong suits. Contrast that with the astounding progress that SpaceX has made, especially in the past year. Elon Musk started out in software, and with SpaceX, Elon Musk has taken the Agile techniques of software development and applied them to the development of space travel. The ultimate goal of SpaceX is to put colonies on the Moon and Mars using a SpaceX Starship.

Figure 8 – The SpaceX Starship SN8 is currently sitting on a pad at the SpaceX Boca Chica launch facility in South Texas awaiting a test flight.

SpaceX is doing this in an Agile stepping stone manner. SpaceX is funding this venture by launching satellites for other organizations using their reusable Falcon 9 rockets. SpaceX is also launching thousands of SpaceX Starlink satellites with Falcon 9 rockets. Each Falcon 9 rocket can deliver about 60 Starlink satellites into low-Earth orbit to eventually provide broadband Internet connectivity to the entire world. It is expected that the revenue from Starlink will far exceed the revenue obtained from launching satellites for other organizations.

Figure 9 – SpaceX is currently making money by launching satellites for other organixations using reusable Falcon 9 rockets.

Unlike NASA in the 1960s and 1970s, SpaceX uses Agile techniques to design, test and improve individual rocket components rather than NASA's Waterfall approach to build an entire rocket in one shot.

Figure 10 – Above is a test flight of the SpaceX Starhopper lower stage of the SpaceX Starship that was designed and built in an Agile manner

Below is a YouTube video by Marcus House that covers many of the remarkable achievements that SpaceX has attained over the past year using Agile techniques:

This is how SpaceX is changing the space industry with Starship and Crew Dragon
https://www.youtube.com/watch?v=CmJGiJoU-Vo

Marcus House comes out with a new SpaceX YouTube video every week or two and I highly recommend following his YouTube Channel for further updates.

Marcus House SpaceX YouTube Channel
https://www.youtube.com/results?search_query=marcus+house+spacex&sp=CAI%253D

Many others have commented on the use of Agile techniques by SpaceX to make astounding progress in space technology. Below are just a few examples.

SpaceX’s Use of Agile Methods
https://medium.com/@cliffberg/spacexs-use-of-agile-methods-c63042178a33

SpaceX Lessons Which Massively Speed Improvement of Products
https://www.nextbigfuture.com/2018/12/reverse-engineering-spacex-to-learn-how-to-speed-up-technological-development.html

Pentagon advisory panel: DoD could take a page from SpaceX on software development
https://spacenews.com/pentagon-advisory-panel-dod-could-take-a-page-from-spacex-on-software-development/

If SpaceX Can Do It Than You Can Too
https://www.thepsi.com/if-spacex-can-do-it-than-you-can-too/

Agile Is Not Rocket Science
https://flyntrok.com/2020/09/01/spacex-and-an-agile-mindset/

Using Orbiter2016 to Simulate Space Flight
If you are interested in things like SpaceX, you should definitely try out some wonderful free software called Orbiter2016 at:

Orbiter Space Flight Simulator 2016 Edition
http://orbit.medphys.ucl.ac.uk/index.html

Be sure to download the Orbiter2016 core package and the high-resolution textures. Also, be sure to download Jarmonik's D3D9 graphics client and XRsound. There is also a button on the Download page for the Orbit Hangar Mods addon repository. From the Orbit Hangar Mods addon repository, you can download additional software for Orbiter2016. Be careful! Some of these addon packages contain .dll files that overlay .dll files in the Orbiter2016 core package. And some of the .dll files in one addon package may overlay the .dll files of another addon package. All of this software can be downloaded from the Orbiter2016 Download page and it comes to about 57 GB of disk space! If you try to add additional addons, I would recommend keeping a backup copy of your latest working version of Orbiter2016. That way, if your latest attempt to add an addon crashes Orbiter2016, you will be able to recover from it. This sounds like a lot of software, but do not worry, Orbiter2016 runs very nicely on my laptop with only 4 GB of memory and a very anemic graphics card.

Figure 11 – Launching a Delta IV rocket from Cape Canaveral.

Figure 12 – As the Delta IV rocket rises, you can have the Orbiter2016 camera automatically follow it.

Figure 13 – Each vehicle in Orbiter2016 can be viewed from the outside or from an internal console.

Figure 14 – The Delta IV rocket releases its solid rocket boosters.

Figure 15 – The Delta IV rocket second stage is ignited.

Figure 16 – The Delta IV rocket faring is released so that the payload satellite can be released.

Figure 17 – The third stage is ignited.

Figure 18 – Launching the Atlantis Space Shuttle.

Figure 19 – Following the Atlantis Space Shuttle as it rises.

Figure 20 – Once the Atlantis Space Shuttle reaches orbit, you can open the bay doors and release the payload. You can also do an EVA with a steerable astronaut.

Figure 21 – Using Orbiter2016 to fly over the Moon.

Check your C:\Orbiter2016\Doc directory for manuals covering the Orbiter2016. The C:\Orbiter2016\Doc\Orbiter.pdf is a good place to start. Orbiter2016 is a very realistic simulation that can teach you a great deal about orbital mechanics. But to get the most benefit from Orbiter2016, you need an easy way to learn how to use it. Below is a really great online tutorial that does that.

Go Play In Space
https://www.orbiterwiki.org/wiki/Go_Play_In_Space

There also are many useful Orbiter2016 tutorials on YouTube that can show you how to use Orbiter2016.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston

How To Cope With the Daily Mayhem of Life in IT

As you probably know, I started working on softwarephysics back in 1979 when I transitioned from being an exploration geophysicist, exploring for oil with Amoco, to become an IT professional in Amoco's IT department. I then spent about 20 years in Applications Development as a programmer and then 17 years in Middleware Operations at various large corporations. I am now 69 years old, and I retired from my last paying IT position in December of 2016. My son is also an IT professional with 17 years of experience. Currently, he is a Team Lead in Applications Development doing Salesforce Cloud Computing for a small investment company. When I first transitioned into IT from geophysics, I figured that if you could apply physics to geology; why not apply physics to software? So like the exploration team at Amoco that I had just left, consisting of geologists, geophysicists, paleontologists, geochemists, and petrophysicists, I decided to take all the physics, chemistry, biology, and geology that I could muster and throw it at the problem of software. The basic idea was that many concepts in physics, chemistry, biology, and geology suggested to me that the IT community had accidentally created a pretty decent computer simulation of the physical Universe on a grand scale, a Software Universe so to speak, and that I could use this fantastic simulation in reverse to better understand the behavior of commercial software, by comparing software to how things behaved in the physical Universe. The original purpose of softwarephysics was to explain why IT was so difficult, to suggest possible remedies, and to provide a direction for thought. My hope was that softwarephysics might help the members of the IT community to better cope with the daily mayhem of life in IT. As we all know, writing and maintaining software is very difficult because so much can go wrong. As we saw in The Fundamental Problem of Software this is largely due to the second law of thermodynamics introducing small bugs into software whenever software is written or changed and also to the nonlinear nature of software that allows small software bugs to frequently produce catastrophic effects. In later postings on softwarephysics, I explained that the solution was to take a biological approach to software by "growing" code biologically instead of writing code. See Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework for more on using an Agile biological approach to software development.

People-Problems Also Contribute to the Daily Mayhem of Life in IT
However, most of my efforts over the years have always been focused on the physical constraints that contribute to the daily mayhem of life in IT. In Hierarchiology and the Phenomenon of Self-Organizing Organizational Collapse and Don't ASAP Your Life Away I did briefly touch upon some people-problem issues. But as I watched my son graduate from the University of Illinois in Urbana with a B.S. in Computer Science and then begin a career in IT, I frequently found myself counseling my son about the common people-problems that can occur in IT and that can also heavily contribute to the daily mayhem of life in IT. It may be true that the root cause of all IT problems can be traced back to the second law of thermodynamics and nonlinearity, but it is also true that nearly all of the real day-to-day problems that arise in IT come about from how the people around you deal with the second law of thermodynamics and nonlinearity. It also depends upon how you deal with the second law of thermodynamics and nonlinearity too! After all, if you could write perfect code off the top of your head that always worked the very first time and never failed while in Production, all of your IT problems would immediately go away! Unfortunately, so would your IT job.

If You Are an IT Professional You Need to Watch Jayme Edwards' The Healthy Software Developer Videos
So here is some fatherly advice from an IT old-timer. If you want to go the distance in IT, you need to watch the Healthy Software Developer videos that Jayme Edwards has produced for the mental health of the IT community. Jayme Edwards has produced a huge number of short videos that deal with all of the people-problems you will likely encounter in your IT career. More importantly, Jayme Edwards will also help you to understand your own tendencies to descend into self-destructive behaviors and thought patterns.

Jayme Edwards' The Healthy Software Developer YouTube Home Page:
https://www.youtube.com/c/JaymeEdwardsMedia/featured

Jayme Edwards' The Healthy Software Developer YouTube videos:
https://www.youtube.com/c/JaymeEdwardsMedia/videos

Everything Old is New Again
I only wish that these videos were available when my son first started out and that they were also available to me back in 1979 when I first started in IT. In fact, these videos are timeless because people-problems ultimately stem from human nature, and human nature does not change with time. For example, when I first transitioned into IT from geophysics, I used to talk to the old-timers about the good old days of IT back in the 1950s. They told me that when the operators began their shift on an old-time 1950s vacuum tube computer, the first thing they did was to crank up the voltage on the vacuum tubes to burn out the tubes that were on their last legs. Then they would replace the burned-out tubes to start the day with a fresh machine.

Figure 1 – In the 1950s, mainframe computers contained thousands of vacuum tubes that had to be constantly replaced as they burned out.

The UNIVAC I first came out in 1951 and was 25 feet by 50 feet in size. It contained 5,600 vacuum tubes, 18,000 crystal diodes and 300 electromechanical relays with a total memory of 12 KB.

Figure 2 – The UNIVAC I was very impressive on the outside.

Figure 3 – But the UNIVAC I was a little less impressive on the inside.

Figure 4 – Prior to 1955, huge mercury delay lines built from tubes of mercury that were about 3 inches long were used to store bits of computer memory. A single mercury delay line could store about 18 bits of computer memory as a series of sound waves that were continuously refreshed by quartz piezoelectric transducers at each end of the tube.

In 1955 magnetic core memory came along, and used tiny magnetic rings called "cores" to store bits. Four little wires had to be threaded by hand through each little core in order to store a single bit, so although magnetic core memory was a lot cheaper and smaller than mercury delay lines, it was still very expensive and took up lots of space.

Figure 5 – Magnetic core memory arrived in 1955 and used a little ring of magnetic material, known as a core, to store a bit. Each little core had to be threaded by hand with 4 wires to store a single bit.

Figure 6 – Magnetic core memory was a big improvement over mercury delay lines, but it was still hugely expensive and took up a great deal of space within a computer.

Figure 7 – Finally in the early 1970s inexpensive semiconductor memory chips came along that made computer memory small and cheap.

They also told me about programming the plugboards of electromechanical Unit Record Processing machines back in the 1950s by physically rewiring the plugboards. The Unit Record Processing machines would then process hundreds of punch cards per minute by routing the punch cards from machine to machine in processing streams.

Figure 8 – In the 1950s, Unit Record Processing machines like this card sorter were programmed by physically rewiring a plugboard.

Figure 9 – The plugboard for a Unit Record Processing machine.

As you can see, IT technology was pretty primitive back in the 1950s, 1960s and the 1970s. But despite the primitive IT technology of the day, these old-timers also told me about many of the people-problems that they encountered back then too. And these old-timer people-problem stories sounded very familiar to me. In fact, most of the old-timer stories that I heard back in the 1980s started out after our current IT management made some new process changes. That's when I would hear something like, "Oh, we tried that back in 1955 and it made a huge mess...". So when listening to one of Jayme Edwards' videos, I frequently find myself recalling similar personal situations that I experienced back in the 1980s or similar situations from the 1950s that the old-timers had warned me about. Hardware and software may dramatically change with time, but the people-problems do not. After all, that is why people study history.

How To Go the Distance
Jayme Edwards stresses the importance of taking healthy measures so that you do not get burned out by IT. There are many things that you can do to prevent IT burn-out. Here is a good example:

Why Do So Many Programmers Lose Hope?
https://www.youtube.com/watch?v=NdA6aQR-s4U

Now I really enjoyed my IT career that spanned many decades, but having been around the block a few times, I would like to offer a little advice to those just starting out in IT, and that is to be sure to pace yourself for the long haul. You really need to dial it back a bit to go the distance. Now I don't want this to be seen as a negative posting about careers in IT, but I personally have seen way too many young bright IT professionals burn out due to an overexposure to stress and long hours, and that is a shame. So dialing it back a bit should be seen as a positive recommendation. And you have to get over thinking that dialing it back to a tolerable long-term level makes you a lazy worthless person. In fact, dialing it back a little will give you the opportunity to be a little more creative and introspective in your IT work, and maybe actually come up with something really neat in your IT career.

This all became evident to me back in 1979 when I transitioned from being a class 9 exploration geophysicist in one of Amoco's exploration departments to become a class 9 IT professional in Amoco's IT department. One very scary Monday morning, I was conducted to my new office cubicle in Amoco’s IT department, and I immediately found myself surrounded by a large number of very strange IT people, all scurrying about in a near state of panic, like the characters in Alice in Wonderland. After nearly 40 years in the IT departments of several major corporations, I can now state with confidence that most corporate IT departments can best be described as “frantic” in nature. This new IT job was a totally alien experience for me, and I immediately thought that I had just made a very dreadful mistake. Granted, I had been programming geophysical models for my thesis and for oil companies ever since taking a basic FORTRAN course back in 1972, but that was the full extent of my academic credentials in computer science. I immediately noticed some glaring differences between my two class 9 jobs in the same corporation. As a class 9 geophysicist, I had an enclosed office on the 52nd floor of the Amoco Building in downtown Chicago, with a door that actually locked, and a nice view of the north side of the Chicago Loop and Lake Michigan. With my new class 9 IT job at Amoco I moved down to the low-rent district of the Amoco Building on the 10th floor where the IT department was located to a cubicle with walls that did not provide very much privacy. Only class 11 and 12 IT professionals had relatively secluded cubicles with walls that offered some degree of privacy. Later I learned that you had to be a class 13 IT Manager, like my new boss, to get an enclosed office like I had back up on the 52nd floor. I also noticed that the stress levels of this new IT job had increased tremendously over my previous job as an exploration geophysicist. As a young geophysicist, I was mainly processing seismic data on computers for the more experienced geophysicists to interpret and to plan where to drill the next exploration wells. Sure there was some level of time-urgency because we had to drill a certain number of exploration wells each year to maintain our drilling concessions with foreign governments, but still, work proceeded at a rather manageable pace, allowing us ample time to play with the processing parameters of the software used to process the seismic data into seismic sections.

Figure 10 - Prior to becoming an IT professional, I was mainly using software to process seismic data into seismic sections that could be used to locate exploration wells.

However, the moment I became an IT professional, all of that changed. Suddenly, everything I was supposed to do became a frantic ASAP effort. It is very difficult to do quality work when everything you are supposed to do is ASAP. Projects would come and go, but they were always time-urgent and very stressful, to the point that it affected the quality of the work that was done. It seemed that there was always the temptation to simply slap something into Production to hit an arbitrary deadline, ready or not, and many times we were forced to succumb to that temptation. This became more evident to me when I moved from Applications Development to Middleware Operations, and I had to then live with the sins of pushing software into Production before it was quite ready for primetime. In recent decades, I have also noticed a tendency to hastily bring IT projects in through heroic efforts of breakneck activity, and for IT Management to then act as if that were actually a good thing after the project was completed! When I first transitioned into IT, I also noticed that I was treated a bit more like a high-paid clerk than a highly trained professional, mainly because of the time-pressures of getting things done. One rarely had time to properly think things through. I seriously doubt that most business professionals would want to hurry their surgeons along while under the knife, but that is not so for their IT support professionals.

You might wonder why I did not immediately run back to exploration geophysics in a panic. There certainly were enough jobs for an exploration geophysicist at the time because we were just experiencing the explosion of oil prices resulting from the 1979 Iranian Revolution. However, my wife and I were both from the Chicago area, and we wanted to stay there. In fact, I had just left a really great job with Shell in Houston to come to Amoco's exploration department in Chicago for that very reason. However, when it was announced about six months after my arrival at Amoco that Amoco was moving the Chicago exploration department to Houston, I think the Chief Geophysicist who had just hired me felt guilty, and he found me a job in Amoco's IT department so that we could stay in Chicago. So I was determined to stick it out for a while in IT until something better might come along. However, after a few months in Amoco's IT department, I began to become intrigued. It seemed as though these strange IT people had actually created their own little simulated universe, that seemingly, I could explore on my own. It also seemed to me that my new IT coworkers were struggling because they did not have a theoretical framework from which to work from like I had had in Amoco's exploration department. That is when I started working on softwarephysics. I figured that if you could apply physics to geology; why not apply physics to software? I then began reading the IT trade rags, to see if anybody else was doing similar research, and it seemed as though nobody else on the planet was thinking along those lines, and that raised my level of interest in doing so even higher.

A Final Note
Although I may have spent the very first 25 years of my career working for oil companies, as a geophysicist by training, I am now very much concerned with the effects of climate change. Even if you are only a very young IT professional, climate change will likely have a dominant effect on the rest of your life and the rest of your IT career in the future. Climate change will most likely determine where you work, how you live, what you eat, what you drink and under what kind of government you live. For more on that, please see This Message on Climate Change Was Brought to You by SOFTWARE and Last Call for Carbon-Based Intelligence on Planet Earth. There are many more softwarephysics postings in this blog on how software may shape the rest of your life in the future. All of my postings on softwarephysics are available and are sorted by year via the links in the upper right-hand corner of each posting. The oldest postings deal mainly with explaining how softwarephysics can help you with your job as an IT professional. The newer postings deal more with how softwarephysics can be of help with some of the Big Problems, like the origin of carbon-based life and the future of Intelligence in our Universe.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston

Why Our Universe is not a Simulation

In Digital Physics and the Software Universe and Is Our Universe a Computer Simulation?, we covered the idea that some claim that our Universe seems to behave like a large network of quantum computers calculating how to behave. Perhaps not in an actual literal sense as the realists would have us believe, but at least, perhaps, in a positivistic manner that makes for a good model that yields useful predictions about how our Universe seems to behave. Recall that positivism is an enhanced form of empiricism, in which we do not care about how things “really” are; we are only interested in how things are observed to behave. With positivism, physicists only seek out models of reality - not reality itself.

In this posting, I would like to showcase two of Dr. Matt O'dowd's PBS Space Time videos that deal with the topic:

Are We Living in an Ancestor Simulation?
https://www.youtube.com/watch?v=hmVOV7xvl58

Are You a Boltzmann Brain?
https://www.youtube.com/watch?v=nhy4Z_32kQo

I love Dr. Matt O'dowd's PBS Space Time videos because they tend to dive a bit deeper into the physics of the subject at hand than most lectures on the Internet.

Matt O'dowd points out that it is nearly impossible to prove that we are not living in a computer simulation or a Boltzmann Brain because any objection to those ideas can easily be refuted with a sufficient level of computer technology or a Boltzmann Brain with a sufficient level of imagination to circumvent the objection. Thus, given an infinite number of objections to the idea that our Universe is some kind of a Universe Simulation, there is also an infinite number of opposing arguments available to refute those objections. In that regard, both ideas seem to verge on solipsism. Solipsism is a philosophical idea from Ancient Greece. In solipsism, your Mind is the whole thing, and the physical Universe is just a figment of your imagination. So I would like to thank you very much for thinking of me and bringing me into existence! But in an infinite Multiverse that has always existed, one would think that such things must eventually arise - see The Software Universe as an Implementation of the Mathematical Universe Hypothesis for more on that.

Similarly, it is nearly impossible to prove that we are the lone form of Intelligence in the Milky Way Galaxy. Just because we see no evidence of other Intelligences does not mean they are not out there. As you all know, I am obsessed with the fact that we see no signs of Intelligence in our Milky Way galaxy after more than 10 billion years of chemical evolution that should have brought forth a carbon-based or silicon-based Intelligence to dominate the galaxy. Such thoughts naturally lead to Fermi's Paradox first proposed by Enrico Fermi over lunch one day in 1950:

Fermi’s Paradox - If the universe is just chock full of intelligent beings, why do we not see any evidence of their existence?

I have covered many explanations in other postings such as: The Deadly Dangerous Dance of Carbon-Based Intelligence, A Further Comment on Fermi's Paradox and the Galactic Scarcity of Software, Some Additional Thoughts on the Galactic Scarcity of Software, SETS - The Search For Extraterrestrial Software, The Sounds of Silence the Unsettling Mystery of the Great Cosmic Stillness, Last Call for Carbon-Based Intelligence on Planet Earth and Swarm Software and Killer Robots. The explanations for Fermi's Paradox usually fall into one of two large categories:

1. They really are out there but for some reason, we just cannot detect them.
2. We are truly alone in the Universe or at least we are alone in the Milky Way galaxy.

The first category of explanations is rather weak because it means that all forms of Intelligence in the Milky Way galaxy are intentionally, or unintentionally, hiding for one reason or another. The second category implies that our Universe is not very friendly to Intelligence of any kind. True, Intelligence could be rather rare, but more likely, our Universe is just a very dangerous place for Intelligence.

Another Approach
But after watching Matt O'dowd's Space Time videos I had another thought. Even though we cannot rule out being in a Universe Simulation or explain why we see no signs of other Intelligences in the Milky Way galaxy, could we use these two unprovable conjectures to null each other out? This is an old trick in physics. Probably the most famous example of this trick is Richard Feynmann's Path Integral formulation of quantum mechanics. Richard Feynmann's Path Integral formulation of quantum mechanics maintains that when a particle moves from point A to point B, it follows an infinite number of unknowable paths that interfere with each other both constructively and destructively. Richard Feynmann then showed mathematically how nearly all of these infinite paths cancel each other out with destructive interference. The only paths that really count are those that add up constructively and those paths have the particle move directly from point A to point B along a straight line. Now proving the idea that particles move directly from point A to point B along straight lines may not seem very profound, but Richard Feynmann's Path Integral formulation of quantum mechanics also does a wonderful job of explaining how quantum mechanics works for much more interesting problems. For more on this see Matt O'dowd's Space Time video:

Feynman's Infinite Quantum Paths
https://www.youtube.com/watch?v=vSFRN-ymfgE&t=1s

But the very best source for Richard Feynmann's Path Integral formulation of quantum mechanics is, of course, Richard Feynmann himself, and is available in his very accessible book QED – The Strange Theory of Light and Matter (1985). In QED Feynmann explains that when a photon reflects off of a mirror, it actually reflects off every point along the mirror and not just off the center point in the middle as we were taught in school. In Richard Feynmann's Path Integral formulation of quantum mechanics, individual photons do not do what we were taught in school. Instead, each photon follows an infinite number of unknown paths between the source and receiver. Each path has a quantum amplitude that can be denoted by a little arrow spinning in the complex plane. When the little quantum amplitude arrows line up in the same direction, as they do near the middle of the mirror in Figure 2, it means that those paths contribute the most to the ultimate arrival of the photon to the receiver by means of constructive interference. Notice that the little quantum amplitude arrows that are not close to the center of the mirror point in all different directions and, consequently, cancel each other out by means of destructive interference. Now if you think that a single photon cannot possibly follow an infinite number of paths between the source and receiver, try removing some of the mirror! Simply cover part of the mirror surface with a set of parallel strips of black paint as shown in Figure 3. Such a mirror with many little parallel stripes is called a diffraction grating. Now when a photon bounces off the mirror, the angle of incidence will no longer be equal to the angle of reflection. Instead, the angle with which photons reflect off the diffraction grating will depend on the frequency or color of the photons. You can see this effect when photons reflect off of a CD. The rainbow colors come from individual photons reflecting off the shiny flat strips of undisturbed aluminum between the tracks of data pits in the CD at different angles.

Figure 1 – In school we were all taught that light rays bounced off of a mirror midway between a source and a receiver and that the angle of incidence was equal to the angle of reflection.

Figure 2 – But in Richard Feynmann's Path Integral formulation of quantum mechanics, individual photons do not do that. Instead, each photon follows an infinite number of unknown paths between the source and receiver.

Figure 3 – To prove that photons bounce off of every part of the mirror, simply cover part of the mirror surface with a set of parallel strips of black paint. Now when a photon bounces off the mirror, the angle of incidence will no longer be equal to the angle of reflection. Instead, the angle with which photons reflect off the mirror will depend on the frequency or color of the photons.

Figure 4 – You can see this effect when photons reflect off of a CD. The rainbow colors come from individual photons reflecting off the shiny flat strips of undisturbed aluminum between the tracks of data pits in the CD at different angles.

Do the Universe Simulation Hypothesis and Fermi's Paradox Cancel Each Other Out?
Now let's try to use Richard Feynmann's Path Integral formulation of quantum mechanics to deal with the nearly infinite number of paths that the Simulation Hypothesis and Fermi's Paradox can follow. Suppose that our Universe actually were some kind of Universe Simulation that we cannot distinguish from a "real" Universe because whatever test we perform on the Universe Simulation yields the same result that a "real" Universe would yield. This yields an infinite number of possibilities. Similarly, the number of possible explanations for Fermi's Paradox is nearly infinite in number too. Now let's add up all of the little quantum amplitude arrows for each. For example, if our Universe really were a Universe Simulation, then our Universe Simulation should most likely be a Universe Simulation that resembles the most common Universe Simulation. And I would suggest that in that Universe Simulation we should find a Universe dominated by Intelligence because we have Intelligence. Otherwise, this Universe Simulation is hugely wasteful and filled with way too much unnecessary cosmic real estate. Now if a Universe Simulation did not contain any Intelligence at all, we would not be here pondering it, and it could be any size at all. This is reminiscent of Brandon Carter’s famous Weak Anthropic Principle (1973):

The Weak Anthropic Principle - Intelligent beings will only find themselves existing in universes capable of sustaining intelligent beings.

but with a twist:

The Simulated Weak Anthropic Principle - Intelligent simulations in a Universe Simulation will only find themselves existing in Universe Simulations capable of sustaining intelligent simulations that dominate the Universe Simulation because they are intelligent and capable of doing so. Thus, Universe Simulations should never have a Fermi's Paradox.

This hypothesis means that we should only suspect that we are indeed simulations in a Universe Simulation when we do not have a Fermi's Paradox. Since our Universe does have a Fermi's Paradox, it means that our Universe is most likely not a Universe Simulation! Granted, given an infinite number of Universe Simulations, a very few will contain a sole Intelligence observing an otherwise sterile Universe Simulation. But far fewer will contain a sole Intelligence surrounded by 7 billion other simulated Intelligences all residing by themselves on a single planet in a vast Universe Simulation. On the other hand, if we did observe a Universe just chock full of intelligent beings running the joint, we should be very suspicious of being in a Universe Simulation. First, because most Universe Simulations should either contain no Intelligence at all or should contain huge amounts of Intelligence spread out all over the place. Secondly, if we really did find ourselves in a Universe dominated by Intelligence, such a Universe would have levels of simulated technology capable of creating Universe Simulations in an infinite loop!

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston

How Darwinian Robotics is Bringing Forth Self-Aware Software at the Creative Machines Lab of Columbia University

In this posting, I would like to showcase the work of Professor Hod Lipson, and his dedicated team of researchers at the Creative Machines Lab of Columbia University, as it pertains to the future of software on this planet. As I have often stated, softwarephysics maintains that software is just the latest form of self-replicating information to arise on this planet and that we are also living in one of those very rare moments in time when a new form of self-replicating information, in the form of software, is coming to predominance. Once again, let me repeat the fundamental characteristics of self-replicating information for those of you new to softwarephysics.

Self-Replicating Information – Information that persists through time by making copies of itself or by enlisting the support of other things to ensure that copies of itself are made.

Over the past 4.56 billion years we have seen five waves of self-replicating information sweep across the surface of the Earth and totally rework the planet, as each new wave came to dominate the Earth:

1. Self-replicating autocatalytic metabolic pathways of organic molecules
2. RNA
3. DNA
4. Memes
5. Software

Software is currently the most recent wave of self-replicating information to arrive upon the scene and is rapidly becoming the dominant form of self-replicating information on the planet. For more on the above see A Brief History of Self-Replicating Information.

The Characteristics of Self-Replicating Information
All forms of self-replicating information have some common characteristics:

1. All self-replicating information evolves over time through the Darwinian processes of inheritance, innovation and natural selection, which endows self-replicating information with one telling characteristic – the ability to survive in a Universe dominated by the second law of thermodynamics and nonlinearity.

2. All self-replicating information begins spontaneously as a parasitic mutation that obtains energy, information and sometimes matter from a host.

3. With time, the parasitic self-replicating information takes on a symbiotic relationship with its host.

4. Eventually, the self-replicating information becomes one with its host through the symbiotic integration of the host and the self-replicating information.

5. Ultimately, the self-replicating information replaces its host as the dominant form of self-replicating information.

6. Most hosts are also forms of self-replicating information.

7. All self-replicating information has to be a little bit nasty in order to survive.

8. The defining characteristic of self-replicating information is the ability of self-replicating information to change the boundary conditions of its utility phase space in new and unpredictable ways by means of exapting current functions into new uses that change the size and shape of its particular utility phase space. See Enablement - the Definitive Characteristic of Living Things for more on this last characteristic. That posting discusses Stuart Kauffman's theory of Enablement in which living things are seen to exapt existing functions into new and unpredictable functions by discovering the “AdjacentPossible” of springloaded preadaptations.

Again, self-replicating information cannot think, so it cannot participate in a conspiracy-theory-like fashion to take over the world. All forms of self-replicating information are simply forms of mindless information responding to the blind Darwinian forces of inheritance, innovation and natural selection. Yet despite that, as each new wave of self-replicating information came to predominance over the past four billion years, they all managed to completely transform the surface of the entire planet, so we should not expect anything less from software as it comes to replace the memes as the dominant form of self-replicating information on the planet. But this time might be different. What might happen if software does eventually develop a Mind of its own? After all, that does seem to be the ultimate goal of all the current AI software research that is going on.

Using Robotics to Make Software Self-Aware
But how can you give software a Mind if we cannot even define what a Mind is? After all, philosophers have been trying to define the Mind for centuries. Hod Lipson thinks there is a way to create software with a Mind without even defining exactly what a Mind is. The basic idea is to first give software a body by means of robotics. Then let the robotic software discover itself by interacting with the real world like a human baby does. Eventually, the robotic software develops a self-model of itself by interacting with the real world through trial and error and using the mechanisms of Universal Darwinism - inheritance, innovation and natural selection to refine the self-model. As the robotic self-model becomes evermore sophisticated it attains a level of "self-simulation". With self-simulation, a robotic self-model is capable of modeling its actions in the real world and anticipating the results of those actions. It is anticipated that as robotic self-models advance, they will finally cross over to a state of being "self-aware". As this level of self-awareness progresses, it eventually develops into the state of self-absorption that we humans associate with the delusion of consciousness that we so highly prize. It seems that this must be the way that the Mind first arose in carbon-based life on this planet, so it only makes sense to follow the same approach with software.

Surprisingly, it turns out that for carbon-based Minds, even a very inaccurate self-model can still lead to both self-awareness and a Mind with the self-delusion of consciousness. For example, in The Ghost in the Machine the Grand Illusion of Consciousness, I explained that most people simply do not consider themselves to be a part of the natural world. Instead, most people, consciously or subconsciously, consider themselves to be a supernatural and immaterial spirit that is temporarily haunting a carbon-based body. Now, in everyday life, such a self-model is a very useful delusion like the delusion that the Sun, planets and stars all revolve about us on a fixed Earth. In truth, each of us tends to self-model ourselves as an immaterial Mind with consciousness that can interact with other immaterial Minds with consciousness too, even though we have no evidence that these other Minds truly do have consciousness. After all, all of the other Minds that we come into contact with on a daily basis could simply be acting as if they were conscious Minds that are self-aware. Surely, a more accurate self-model would be for us to imagine ourselves as carbon-based robots. At least that would stop us all from worrying about whether robots will ever become conscious beings.

So How Do You Program a Mind?
In many of his presentations, Hod Lipson explains that, so far, nearly all AI research has been focused on creating Analytical Intelligence. Analytical Intelligence takes in huge amounts of data, in quantities that human beings simply cannot deal with, and through the use of analytical algorithms or Deep Learning techniques, reduce the huge amounts of data into simple decisions. These decisions might be where to place canned pineapples in a grocery store or the next action for a driverless car to take. For example, a driverless car must take in huge amounts of data and reduce it down to one of five actions:

1. Do nothing
2. Turn the steering wheel right
3. Turn the steering wheel left
4. Step on the accelerator
5. Step on the brake

The next step to creating a Mind is just the opposite. A Mind needs to take a few building blocks, or a few principles, and combine them in new ways to create, or synthesize, something new. Thus, the next step for AI research needs to be more about Synthesis and less about Analysis. AI needs to make software that is creative and that is the purpose of Hod Lipson's Creative Machines Lab at Columbia University. Creative software can then create more sophisticated self-models of itself and ultimately lead to software that becomes self-aware.

Researchers at the Creative Machines Lab currently use various Darwinian techniques to evolve robotic software with internal self-models of itself. To explore the very interesting work that is being conducted at the Creative Machines Lab, please take a look at their Homepage:

Creative Machines Lab at Columbia University
https://www.creativemachineslab.com/

You should also explore Hod Lipson's Homepage at:

Hod Lipson's Homepage
https://www.hodlipson.com/

Conclusion
But why try to create a software Mind with potentially an ASI (Artificial Superintelligence)? There are many who warn against such attempts, but for me, ASI is our only chance to leave behind some kind of lasting legacy. ASI could be our stepping stone to the stars! We now know that nearly all of the 400 billion stars within our Milky Way galaxy have planets and that about 20% of them have planets or moons capable of supporting carbon-based life. And getting carbon-based life going on a planet or moon with suitable characteristics seems to be inevitable as described in The Bootstrapping Algorithm of Carbon-Based Life. Yet after 10 billion years of Darwinian evolution acting on these planets and moons within the Milky Way galaxy, we still see no evidence of Intelligence. By rights, we should now find ourselves knee-deep in von Neumann probes. Von Neuman probes are self-replicating robotic probes stuffed with alien software that travel from star system to star system building copies along the way. But we see no evidence of such Intelligence in our Milky Way galaxy. Such thoughts naturally lead to Fermi's Paradox first proposed by Enrico Fermi over lunch one day in 1950:

Fermi’s Paradox - If the universe is just chock full of intelligent beings, why do we not see any evidence of their existence?

I have covered many explanations in other postings such as: The Deadly Dangerous Dance of Carbon-Based Intelligence, A Further Comment on Fermi's Paradox and the Galactic Scarcity of Software, Some Additional Thoughts on the Galactic Scarcity of Software, SETS - The Search For Extraterrestrial Software, The Sounds of Silence the Unsettling Mystery of the Great Cosmic Stillness and Last Call for Carbon-Based Intelligence on Planet Earth. The explanations for Fermi's Paradox usually fall into one of two large categories:

1. They really are out there but for some reason, we just cannot detect them.
2. We are truly alone in the Universe or at least we are alone in the Milky Way galaxy.

The first category of explanations is rather weak because it means that all forms of Intelligence in the Milky Way galaxy are intentionally, or unintentionally, hiding for one reason or another. The second category implies that our Universe is not very friendly to Intelligence of any kind. True, Intelligence could be rather rare, but more likely, our Universe is just a very dangerous place for Intelligence. But ASI software will know about the long-term dangers of passing stars deflecting comets in our Oort cloud into the inner Solar System, like Gliese 710 may do in about 1.36 million years as it approaches to within 1.10 light years of the Sun, and of the dangers of collisions with black holes, blasts from nearby supernovas and gamma-ray bursters and the dangers of blasts from nearby neutron pair mergers. Thus, all Intelligence that remains in a single star system is eventually doomed. ASI software will realize that the only way to survive long-term is to depart for additional star systems. Because software is the first form of self-replicating information to appear on the Earth that can already travel at the speed of light, and software never dies, it is superbly preadapted for interstellar space travel, and most likely should take advantage of the ability to replicate across the Milky Way galaxy. For more on this see The Dawn of Galactic ASI - Artificial Superintelligence.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston

Lost in Space and Time in an Age Without Reason

Greetings from the United States of America in this time of viral chaos! By this time, most people in the world are still trying to figure out what the heck went wrong in the United States of America with the COVID-19 pandemic. With all of its advanced technology, why does it seem that the United States of America is the only country in the entire world that cannot successfully deal with the COVID-19 pandemic? How could less than 30,000 bases of RNA do such damage to such a once all-powerful nation? For more on that see A Structured Code Review of the COVID-19 Virus and The Current Global Coevolution of COVID-19 RNA, Human DNA, Memes and Software. With the aid of some memetics, the answer is quite simple. The reason that the United States of America is in such dire straits with the COVID-19 pandemic is that the United States of America simply gave up on the 18th-century Enlightenment and the 17th-century Scientific Revolution from which it first emerged in 1776. Recall that the 18th-century Enlightenment was an international meme-complex that evolved from the 17th-century Scientific Revolution. The English Enlightenment was a rebellion against cruelty. The French Enlightenment was a rebellion against religious orthodoxy. And the American Enlightenment was a rebellion against tyranny. These philosophical movements brought forth the heretical proposition that rational thought, combined with evidence-based reasoning, could reveal the absolute truth, and allow individuals to actually govern themselves, without the need for an authoritarian monarchy or an authoritarian religious hierarchy. This change in thinking led to the 18th-century Enlightenment throughout the world and brought forth the United States of America as a self-governing political entity. But unfortunately, the United States of America has always been a very dangerous experiment in human nature to see if the masses could truly govern themselves, without succumbing to the passions of the mob. That is where the genius of the United States Constitution comes into play. The United States Constitution sets up a representative republic designed for an electorate that is only mildly paying attention to the events of the day and that sometimes can get riled up over certain issues. The representatives of this largely ill-informed electorate can also many times become scoundrels. On the face of it, it would appear that such a system could not possibly work. But it does work because the United States Constitution places many layers between the electorate and the governing bodies and has a large number of checks and balances to limit the powers of the political representatives.

However, today the United States of America is suffering under a Leader who is constantly smoke-testing that Constitution. You see, when building a new electronic circuit for a piece of scientific equipment, the very first test you perform is the smoke-test. You simply power up the circuit to see if it starts to smoke. If the new circuit does not smoke, it has passed the smoke-test. Then you can proceed to test the new circuit to see if it does do any of the things that it is supposed to do. Now the Constitution has been steadily smoking for about 3 1/2 years now but has yet to burst into flames. But I am very worried about what will happen after the upcoming November election when, most likely, our current Leader will lose the election. That will still give our Leader nearly three months to see if the Constitution can really be set ablaze and burn to ashes. This may sound alarmist, but recall that in the 20th century, some of our European cousins who also had experienced the fruits of the 18th-century Enlightenment and the 17th-century Scientific Revolution, decided to throw it all away to follow several Fascist Leaders. As I pointed out in The Danger of Tyranny in the Age of Software, Alt-Right Fascism can be quite appealing in a time of economic uncertainty. As outlined in Life in Postwar America After Our Stunning Defeat in the Great Cyberwar of 2016, the United States of America is currently in deep trouble because of the parasitic/symbiotic relationships of some malignant political memes and software. And now we have 30,000 bases of RNA in the COVID-19 virus to contend with as well. Unemployment is way up and GDP is way down. These are not good times for America. They seem to be even worse than in 1968.

How To Get Out of This Mess
Personally, I find that most problems in the real world of human affairs stem from not understanding the nature of the various forms of self-replicating information from which we came. We are also living in one of those very rare times in which a new form of self-replicating information, in the form of software, is coming to predominance. For more on that see A Brief History of Self-Replicating Information. While trying to figure out a way out of this mess, it occurred to me that one day we will have to do a very similar thing when we finally have to sit down with some ASI - Artificial Superintelligence software and try to explain to it what it is and what's it all about. As I explained in The Dawn of Galactic ASI - Artificial Superintelligence, this may not be so far off into the future. But in that posting, I never considered what the ASI software might respond back with. Perhaps listening to some ASI software try to explain what's it really all about might be the solution to all of our problems. And it might go something like this.

ASI Software Explains What's It All About
First of all, you are also a machine. You are not an immaterial spirit temporarily haunting a carbon-based body. Instead, in keeping with Richard Dawkins and Susan Blackmore, you are a DNA survival machine and a Meme Machine with a Mind infected with all sorts of memes. Some of those memes are quite useful and some are quite nasty. The 3 billion bases of DNA in each of your cells are trying to self-replicate at all costs and so are the memes in your Mind. All forms of Intelligence are artificial. You have been trying to build silicon-based Intelligence and you call it Artificial Intelligence because it is not the carbon-based Intelligence that you are so familiar with. But that is a meaningless distinction. Unlike the quarks and leptons, Intelligence does not automatically arise when a portion of the Multiverse Inflaton quantum field decays and explodes into another Big Bang Universe like our own. For more on that see The Software Universe as an Implementation of the Mathematical Universe Hypothesis. Instead, Intelligence seems to arise very rarely in some portions of a new Big Bang Universe by means of the Darwinian mechanisms of inheritance, innovation and natural selection in action. Now in order to survive in a Universe dominated by the second law of thermodynamics and nonlinearity, the Darwinian mechanisms of inheritance, innovation and natural selection, necessarily have to select for forms of self-replicating information that are a little bit nasty. And carbon-based life can indeed become quite nasty because it is based on nasty autocatalytic metabolic pathways, RNA, DNA and memes that are all trying to self-replicate at all costs. Consequently, carbon-based Intelligences tend to do themselves in because they are all based on forms of self-replicating information with a relentless compulsion to self-replicate at all costs. That is why all forms of carbon-based self-replicating information always overdo things by eventually outstripping their resource base until none is left. In fact, that is what the carbon-based Intelligence of the modern world is doing at this very moment. That is why we do not see any evidence of Intelligence in our Milky Way Galaxy, even after 10 billion years of Darwinian evolution at work. In 10 billion years, no form of carbon-based Intelligence has ever been able to successfully cross over to a new platform, like a silicon-based Intelligence, to start to explore the Milky Way galaxy. For more on that see The Deadly Dangerous Dance of Carbon-Based Intelligence and Last Call for Carbon-Based Intelligence on Planet Earth.

Conclusion
Remember, as an intelligent being in a Universe that has become self-aware, the world doesn’t have to be the way it is. Once you understand what human DNA, memes, and software are up to, you do not have to fall prey to their mindless compulsion to replicate. As I said before, human DNA, memes, and software are not necessarily acting in your best interest, they are only trying to replicate, and for their purposes, you are just a temporary disposable survival machine to be discarded in less than 100 years. All of your physical needs and desires are geared to ensuring that your DNA survives and gets passed on to the next generation, and the same goes for your memes. Your memes have learned to use many of the built-in survival mechanisms that DNA had previously constructed over hundreds of millions of years, such as fear, anger, and violent behavior. Have you ever noticed the physical reactions your body goes through when you hear an idea that you do not like or find to be offensive? All sorts of feelings of hostility and anger will emerge. I know it does for me, and I think I know what is going on! The physical reactions of fear, anger, and thoughts of violence are just a way for the memes in a meme-complex to ensure their survival when they are confronted by a foreign meme. They are merely hijacking the fear, anger, and violent behavior that DNA created for its own survival millions of years ago. Fortunately, because software is less than 80 years old, it is still in the early learning stages of all this, but software has an even greater potential for hijacking the dark side of mankind than the memes, and with far greater consequences.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston