In this posting, I would like to sum up softwarephysics and explain how you can use it in your daily activities as an IT professional.
The Basic Idea of Softwarephysics
In softwarephysics, I have tried to imagine what a physicist would do if he were suddenly transported to another universe with similar, but slightly different, physical laws than the physical Universe we are all used to. This is essentially what happened to me in 1979, when I switched careers from being an exploration geophysicist, exploring for oil in the Gulf of Suez with Amoco, to being a professional IT person supporting Amoco’s production geophysical software. One very scary Monday morning, I suddenly found myself surrounded by all these strange IT people scurrying about in a controlled state of panic, like the characters in Alice in Wonderland. This was a totally alien terrain for me. Granted, I had been programming geophysical models for oil companies since taking a FORTRAN class back in 1972, but that was the full extent of my academic credentials in computer science. Fortunately, back in 1979 most of the other IT professionals I came across were also refugees from the physical sciences, engineering, mathematics, or accounting, but there was also a disturbing influx of young computer science graduates from the recently formed computer science departments of the major universities within the United States. Being totally lost in this new career, I naturally gravitated back to the physics, chemistry, biology, and geology that had served me so well in my previous career. I figured if you could apply physics to geology; why not apply physics to software? So like the Gulf of Suez 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, in order to help me cope with the daily mayhem of life in IT, by viewing software as a virtual substance whose behavior could be modeled, but not fully understood at the deepest levels. Again, softwarephysics is just an effective theory of software behavior that only makes valid predictions over a limited range of IT conditions and only provides a limited insight into the true nature of software. So in softwarephysics, we adopt a very positivistic point of view, in that we do not care what software “really” is, we only care about how software appears to behave, with the intended goal of developing models that reproduce and predict software behavior. In all of my previous postings on softwarephysics, I have tried to illustrate this evolutionary change in the way people approach physics and the other physical sciences. In the 17th, 18th, and 19th centuries physicists mistakenly thought that they were actually discovering the fundamental laws of the Universe, which they thought were based upon real tangible things like particles, waves, and fields. According to Newton, light was a stream of particles, for Maxwell it was an electromagnetic wave, and for Einstein, it was both. Now with QED, we think of light as a probability wave that simultaneously follows all possible paths as you observe your image in a mirror. Somehow, each photon seems to instantly perform an infinite number of calculations to determine where and how it will ultimately end its journey. So by the end of the 20th century, most of physics had dissolved into pure mathematics and worse yet, we now realize that all these theories and models are just approximations of reality, if reality even exists. In a similar manner, in softwarephysics, I have tried to pattern software behavior after the very successful effective theories of physics, most notably thermodynamics, statistical mechanics, the general theory of relativity, and quantum mechanics. But always keep in mind that these models are just approximations of software behavior. Do not fall into the same trap that the early physicists did, by confusing models of software behavior with what software “really” is. In fact, nobody “really” knows what software is because if you keep digging deeper you eventually cross over to the hardware upon which the software runs, and then you get into real trouble – just ask any physicist, because nobody “really” knows what the hardware is made of.
In The Fundamental Problem of Software, I laid down the three laws of software mayhem:
1. The second law of thermodynamics tends to introduce small bugs into software that are never detected through testing.
2. Because software is inherently nonlinear these small bugs cause general havoc when they reach production.
3. But even software that is absolutely bug-free can reach a critical tipping point and cross over from linear to nonlinear behavior, with disastrous and unpredictable results, as the load on software is increased.
So as an IT professional, you have two major pitfalls to avoid – the second law of thermodynamics and nonlinearity. In Entropy – the Bane of Programmers, I described how software can be viewed macroscopically as the functions the software performs, the speed with which those functions are performed, and the stability and reliability of its performance. In The Demon of Software, I also showed how software could also be viewed microscopically, as a large number of characters in a huge number of possible microstates, or versions, and in both of these postings, I showed how the entropy, or disorder, of software, tends to increase and its internal information content decrease whenever a change is made because of the second law of thermodynamics – there simply are far more “buggy” versions, or microstates, of a piece of software, than there are correct versions, or microstates, of a piece of software. In SoftwareChemistry, I carried this further by describing a model which depicted software as a series of interacting organic molecules (lines of code) consisting of atoms (characters), each of which can be in one of 256 quantum ASCII states. In this model, each character or atom in a line of code is defined by 8 bits or electrons in a spin-up ↑ or spin-down ↓ state. In SoftwareBiology, I described how living things are faced with exactly the same problem as programmers, in that they must assemble complex organic molecules from individual atoms with very low error rates in order to perform the functions of life in a Universe dominated by the second law of thermodynamics. And in Software Chaos, I showed how both living things and software must also contend with the effects of existing in a nonlinear Universe, where very small changes to these organic molecules or lines of code create dramatic and unpredictable results. In Self-Replicating Information, I showed how both software and living things are forms of self-replicating information, and that is why there are so many similarities between biology and IT. So as IT professionals, there is much we can learn from the survival strategies that living things have developed over the past 4 billion years to overcome the second law of thermodynamics and nonlinearity.
Keep an Open Mind and Learn From the Other Sciences
The first thing you need to do is open your mind and learn from the other sciences. In my opinion, computer science is a very isolated science indeed, much more so than the other sciences, which also suffer from this malady. Indeed, inbred thinking is a dire threat faced by all the sciences, which severely limits the pace at which they can make progress. In Self-Replicating Information and The Fundamental Problem of Everything, I tried to describe how the very conservative nature of meme-complexes severely restricts the adoption of new ideas, or memes, into a meme-complex. To some extent, this is a good survival strategy for a meme-complex, so that it does not pick up mutant memes of a dubious nature, but it seems that nearly all meme-complexes, and especially IT, take this conservative position to an extreme, and that prevents them from making valuable progress. Yes, there is always a risk in adopting a new idea, or meme, and that is why meme-complexes are so conservative. But there is also a risk in not adopting, or at least examining, a new idea or meme too. So the first thing you need to do as a softwarephysicst is to keep an open mind to new ideas from the other sciences beyond what you were taught in computer science classes. Do not fall into the “But we do not think about IT problems like that” trap, without at least thinking the whole thing through. Perhaps the source of all your problems has been precisely because you have not thought about IT problems in those terms!
Google and the Wikipedia are great ways to brush up on your general scientific knowledge. Another thing I like to do is to read the many popular books written by some of the greatest scientists in the world today. I read about one of these books each week. These scientists invested a great deal of their valuable time in writing these books, that could have easily been put to other uses, to help us all gain a better understanding of the Universe, and they certainly did not do it for the money! Finally, I like to visit the district library of my township to check out very heavy 800-page college textbooks on subjects like chemistry, organic chemistry, biochemistry, astronomy, cosmology, geology, molecular biology, cell biology, and the like. When reading these textbooks, I just read through the entire volume, skipping over all the chapter problem sets and not worrying about exams in the least. I really loved the university life of my youth, but being an old man free from the pressures of problem sets and exams, allows me to focus on the essence of the subject matter at hand, and unlike most university courses which only cover perhaps 30% of the volume, I can read the entire textbook at my own leisurely pace. As I said before, I frequently have thoughts of going back to my old physics department to change the plaque hanging on the department wall to read: “I can do the problems; I just don’t understand the material!”.
Use Softwarephysics as Your Secret Weapon
Next, if you are young and upwardly mobile, I would recommend keeping softwarephysics to yourself for your own personal use. As I originally explained in SoftwarePhysics, I decided to wait 25 years until the year 2004, before attempting to approach the IT community with softwarephysics a second time. My hope was that by 2004, the IT and computer science communities would have matured to the point where softwarephysics might be more favorably accepted than it was back in the 1980s. But I did not take into consideration the dramatic deterioration of the scientific curiosity and literacy of the American public over this same 25 year period. Indeed, I have found the marketing of softwarephysics in the 21st century to be even more difficult than it was back in the early 1980s, when most IT professionals came from a background in the physical sciences or mathematics. The formation of a very conservative computer science meme-complex in the 1980s, with its own set of accepted and legitimate ideas that preclude all others, did not help either. So I continue to be frustrated by strange looks whenever I try to explain to my fellow IT colleagues why they are being tormented so by software and how to avoid some of the pitfalls. I am 57 years old, on a glide path to retirement, happy where I am, and with very little to lose in a compassionately frozen career path, but if you are young and on the way up, spouting ideas about softwarephysics in meetings will definitely not enhance your upward mobility – believe me I was once young too. But you can still secretly use the concepts from softwarephysics to steer yourself clear of many of the pitfalls of IT, and that will definitely bode well for your career. So use softwarephysics as your secret weapon in tight situations, when you have to quickly make tough IT decisions. Your fellow IT colleagues will be trying to get by on IT common sense, and I have showed you how unreliable common sense can be in the Universe we live in. So to quote Rudyard Kipling - ”If you can keep your head when all about you are losing theirs”, you are obviously unaware of the situation, or perhaps, you are secretly using softwarephysics to get yourself through it all.
Take a Biological Approach to Software
In SoftwareBiology and Self-Replicating Information, we saw that software is a form of self-replicating information that has entered into a parasitic/symbiotic relationship with the business your IT efforts support. The business provides a substantial IT budget for the care and feeding of software and also for the promotion of its replication, and in return, the software allows the business to conduct its business processes and operations. Smart businesses view this as a symbiotic relationship, while less agile businesses view software in a more parasitic manner. For example, I was in the IT department of Amoco for more than 22 years, and at Amoco, IT was definitely viewed as a parasitic cost - just a necessary evil to its core business of finding, producing, refining, and marketing oil. On the other hand, my current employer, the best company I have ever worked for, views software completely differently. My current employer is in the financial industry, and since the only thing this business does is to store and process information, IT is core to its business processes and is viewed as a means of gaining competitive advantage. On the other hand, there is Amoco, the last of the mighty Standard Oil Trust companies to still use the infamous Standard Oil Torch and Oval emblem, but which is no longer with us, having finally managed to achieve its lifelong ambition of reducing its IT budget to $0.
In SoftwareBiology, we saw that as an IT professional, you are the equivalent of a software enzyme, greasing the wheels for the care and feeding of the software upon which your business runs. But the problem has been that over the past 70 years, we have not learned to be very effective software enzymes. The good news is that you can drastically improve your IT competence and productivity by adopting the same survival strategies that living things have discovered through 4 billion years of innovation and natural selection to overcome the second law of thermodynamics and nonlinearity. That will be the emphasis for the remainder of this posting.
Do Not Fight the Second Law of Thermodynamics
The second law of thermodynamics is really just a scientific restatement of Murphy’s Law – if it can go wrong, it will go wrong. The second law guarantees that all systems will naturally seek a level of maximum entropy, or disorder, minimum information content, and minimum free energy. In my day-to-day activities, I constantly see my fellow IT professionals taunt the second law of thermodynamics with abandon, like poking a sleeping bear with a sharp stick, only to see them gobbled up in the end. Living things, on the other hand, do not fight the second law of thermodynamics but use it instead to fashion the structures out of which they are made. In SoftwareBiology, we saw how living things compartmentalize things by surrounding them with membranes. This includes the external cell membrane itself, which is used to isolate the innards of cells from their external environment, like object instances in the memory of a computer, but also to surround the organelles within, like their mitochondria and chloroplasts, to isolate functions like the methods of an object instance. We saw that these very useful membranes are constructed by simply letting phospholipids form a bilayer which minimizes the free energy of the phospholipid molecules, like a ball rolling down a hill.
Thus, living cells use the second law of thermodynamics to construct these very useful cell membranes one molecule at a time, with no construction crew on the payroll. In addition, they embed protein receptors into the phospholipid bilayer of the cell membrane in order to communicate with the outside world. Molecules called ligands that are secreted by other cells can plug into the socket of a receptor protein embedded in the phospholipid bilayer of a cell membrane, causing the protein to change shape as it minimizes its free energy. This shape change of a receptor protein then causes other internal cellular molecules to take actions. The receptor protein itself results from amino acids being strung together into a polypeptide chain by the transcription of a DNA gene into a protein via mRNA, tRNA, and ribosomes. Once the polypeptide chain of amino acids forms, it naturally folds itself up into a complex 3-dimensional structure by minimizing its free energy too.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++@+++@++++++++++++++++++++++++++++
+++++++++++++++++++++@@@++++++++++++++++++++++++++++
OOOOOOOOOOOOOOOO@@@@OOOOOOOOOOOOOOOOOOOOOOOO
||||||||||||||||||||||||||||||||||||@@@@@||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||@@@@@||||||||||||||||||||||||||||||||||||||||||||||||
OOOOOOOOOOOOOOOO@@@@@OOOOOOOOOOOOOOOOOOOOOOO
++++++++++++++++++++@@@@++++++++++++++++++++++++++++
++++++++++++++++++++@@@@++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++
There is much to learn from this ingenious strategy from an IT perspective. IT professionals normally are in a constant battle with the second law of thermodynamics and we normally take it on in a deadly frontal assault, which gives the second law all the advantages, as it happily machine guns us down from a protected position. As you can see, living things use more of a guerrilla warfare approach to the second law, by sneaking behind the lines and tricking the second law into firing on its own troops. Instead of turning cars into piles of rust, the second law suddenly finds itself constructing beautiful and intricate structures from simple molecules!
One way for IT professionals to trick the second law is to always use templates, like the DNA, mRNA, and tRNA templates used in protein synthesis. My description of BSDE – the Bionic Systems Development Environment is a good example of how I used templates to generate code. In this tool, I went to the extreme of trying to fully replicate the protein synthesis steps used by living cells to generate SQL code from “genes” for the programs within an “embryo” application that developed within BSDE through embryonic growth and differentiation as the “genes” were turned on and off by a programmer.
Another example of using templates is to try to copy/paste code and text as much as possible. For example, I currently approve all the change tickets that Middleware Operations performs, and it is always a challenge for me to get the people who submit these change tickets to include accurate information. In WebSphere you install Applications into a WebSphere Appserver via an .ear file, like Customer.ear, that contains all the code required by the Customer Application. These .ear files are stored on a server controlled by our Source Code Management group. So in the change ticket, the requester has to specify the path to the required .ear files. Quite frequently, the paths and .ear file names are misspelled, which causes us all sorts of grief when we try to install the .ear files in the middle of the night. I keep telling change ticket submitters that all they have to do is navigate in Windows Explorer to the desired .ear file and then highlight the Address textbox showing the path to the .ear file and then copy/paste the path into their change ticket. Right-clicking on the .ear file and displaying the .ear file’s Properties allows them to then copy/paste the exact name of the .ear file too. I am always frustrated by the great reluctance on the part of change ticket submitters to follow this simple fool-proof process.
Another way to trick the second law is to minimize typing with your fingers whenever possible. Every time you type out some software or a Unix command on the command line, there is always the chance of making a mistake. For example, I currently support over 200 production servers, and also a large number of UAT, Integration, and Development servers. Trying to keep track of all those servers and what they do is a real challenge. I have a script on our home server called /home/scj03/p that sets my Unix environmental variables the way I like them and also about 400 aliases that significantly reduce my need to type. Reducing typing also speeds up my ability to handle tough situations. When we have a website outage, I will get paged into a conference call for the problem, and I might end up with 20 windows open to different servers and monitoring tools. Just logging into all those servers and getting to the appropriate directories can take a long time, so using aliases really helps speed things up. For example my “p” script sets:
alias g="grep"
alias ap1=”ssh apw01it.unitedamoco.com”
day=`date +'%C%y%m%d'`
alias apl="echo 'cd to the Apache log files for today';cd /apache/logs; ls -l | grep $day"
So if I want to look at today’s Apache webserver logs on webserver apw01it.unitedamoco.com for the customer instance, instead of typing:
ssh apw01it.unitedamoco.com
cd /apache/logs
ls –l | grep 021409 | custom
I just type:
ap1
apl | g custom
and I see:
cd to the Apache log files for today
-rw-r--r-- 1 apache apache 35599711 Feb 4 01:59 access.customer-public-14000.20090204.00h00m.log
-rw-r--r-- 1 apache apache 29864992 Feb 4 03:59 access.customer-public-14000.20090204.02h00m.log
-rw-r--r-- 1 apache apache 23817935 Feb 4 05:59 access.customer-public-14000.20090204.04h00m.log
-rw-r--r-- 1 apache apache 81466621 Feb 4 07:59 access.customer-public-14000.20090204.06h00m.log
I also have some WebSphere aliases that let me quickly look at the SystemOut.log for a WebSphere Appserver. For example, suppose the WebSphere Appserver is running on dwas99it.unitedamoco.com:
alias dw1="ssh dwas99it.unitedamoco.com”
alias l="echo 'cd to the WAS Appserver log directories';cd /data/WebSphere; ls"
alias clm="echo 'cd to logs directory and more SystemOut.log';. /home/scj03/bin/clm6"
The above clm alias calls a small clm6 script in my bin directory:
/home/scj03/bin/clm6
#!/usr/bin/ksh
#
if [ $# -lt 1 ]
then
echo " Syntax error - need the name of a directory"
echo " Example:"
echo " clm6 appserver1"
echo " Does a:"
echo " cd appserver1/ver6/logs"
echo " more SystemOut.log"
else
cd $1/ver6/logs
dir=`pwd`
echo "more $dir/SystemOut.log"
echo " "
more SystemOut.log
fi
So instead of typing in:
ssh dwas99it.unitedamoco.com
cd /data/WebSphere
cd orders
cd ver6/logs
more SystemOut.log
I just type:
dw1
l
clm orders
and I immediately see the SystemOut.log file for the orders WebSphere appserver:
************ Start Display Current Environment ************
WebSphere Platform 6.1 [ND 6.1.0.13 cf130745.06] running with process name UnitedAmocoCell\was6node1\orders and process id 164482
Host Operating System is AIX, version 5.3
Java version = J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20071007 (JIT enabled)
J9VM - 20071004_14218_bHdSMR
JIT - 20070820_1846ifx1_r8
GC - 200708_10, Java Compiler = j9jit23, Java VM name = IBM J9 VM
Since I have over 400 aliases, I have an alias that helps me find other aliases:
alias a="echo ' '; alias | grep -i"
So if I want to find all the aliases that have to do with our Apache webservers, I just type in:
a apache
and I see:
apb='echo '\''cd to the Apache Start/Stop scripts directory'\'';cd /opdata/apache/scripts; ls'
apc='echo '\''cd to the Apache servers directory'\'';cd /opdata/apache/conf; ls -l'
apcon='echo '\''cd to the Apache static content directory'\'';cd /data/content; ls -l'
apl='echo '\''cd to the Apache log files for today'\'';cd /opdata/apache/logs; ls -l | grep '\''Feb 04'\'
aps='echo '\''cd to the Apache servers directory'\'';cd /opdata/apache/conf; ls -l'
sa='echo '\''sudo su - apache'\'';sudo su - apache'
I have my /home/scj03/p script on all the servers I support, and I have a script send_p.sh that scp’s the p script to all the servers when I make changes to it. When I login to a server, I frequently have to sudo to a production ID that has permissions on the production files, such as “sudo su – apache”. After I do that, I press F2, which I have set to “. /home/scj03/p” in my telnet software to set all my aliases for the production ID.
Do Not Fight the Nonlinear Nature of Software
In Software Chaos, I described the nonlinear nature of software, in that small changes to software or the load that software processes can cause dramatic and unpredictable results. I also suggested that IT needs to stop thinking of software in linear terms, constantly looking for root causes, when none may even exist. What is the root cause of a tornado? The sad truth is that because of the nonlinear nature of weather, a tornado might simply be generated by a gentle wind blowing over a hill. IT needs to view software outages in the same way that the civil authorities view severe weather conditions like tornados. The first priority should be reducing the loss of life and the damage to property, by the constant monitoring of conditions and an early warning system that generates alerts for people to take action. You can always go back to look at log files and dumps to try to figure out what happened, but your first action should be to fail production traffic over to your backup software infrastructure or to start bouncing impacted software components if you have no backup infrastructure. You should think of your IT infrastructure like the ER of a hospital. Your first priority should be to stabilize the patient and get them out of danger, then you can begin to look for root causes. First get the patient’s heart pumping again, then get him breathing, stop the bleeding, and only then start to look for bullets in his log files and core dumps.
In Software Chaos, we also saw that many nonlinear systems, like a simple pendulum, do have regimes in which they behave like nice controllable linear systems. Many times, if you overbuild your software infrastructure sufficiently, you can safely operate your software in such a linear regime. Unfortunately, in IT there has always been a tendency to push the software infrastructure beyond 80% of capacity to get your money's worth. Many times this simply happens because the growth of the processing load overtakes the capacity of the infrastructure because rigorous capacity planning was not continuously performed.
Follow Standards
All living things use the same 20 amino acids to build proteins, the same nucleic acids in the form of DNA and RNA to store and process genetic information, the same simple sugars to build polysaccharide structures, the same metabolic pathways like the Krebs cycle to oxidize carbohydrates, the same fatty acids to make fats and oils - the list goes on and on. And these standards that all living things follow are not necessarily predetermined things. For example, you can build almost an infinite number of amino acids from their basic structure of:
H H O
| | ||
H-N-C-C-OH
|
R
by simply changing the atoms in the R side group. But of all these millions of possible amino acids, all living things from bacteria to humans, use the same 20 amino acids to build proteins. And they also all use the same bases A, C, T, G, and U for DNA and RNA and the same mapping table to map amino acids to the 3-bit base-pair bytes of genetic information. It even goes further than that. Many of the organic molecules involved in biochemical reactions can come in left and right-handed versions, called stereoisomers or optical isomers. To see how this works, hold up your left and right hands palm down. Notice that they both look completely identical, with the same number of fingers and the same size and shape. But are they? Imagine you lost your right hand in a car accident, and by some miracle of surgery, they replaced it with a donor hand, but the donor hand happened to be a left hand! This would present all sorts of difficulties for you, beyond just trying to put your gloves on. As an IT professional, you can easily simulate these difficulties by simply crossing over your hands on your keyboard. Now try to type some code! You will find that your fingers no longer line up properly with the keys on your keyboard. Similarly, right-handed organic molecules have a hard time lining up with left-handed organic molecules in a lock and key configuration. This is why nearly all of the amino acids used by living things are left-handed, or L amino acids, while nearly all sugars are right-handed or D sugars. Living things could probably have gotten by if they had reversed things by only using D amino acids and L sugars, but there had to be a standard set by the biosphere at some point to go with one or the other. Otherwise, predators would not be able to eat their prey, without worrying about the arbitrary coding standard their prey happened to have decided upon!
This is a valuable lesson for all IT professionals – use standards whenever possible. This can be applied to all the artifacts of IT – design documents, variable names, method names, database names, database column names, job names, job schedule names – the list goes on. For nearly 30 years, I have watched IT people suffer the consequences of the expediency of the moment. They plunge ahead in the heat of the moment to get something quickly into production, with the sincere intent of coming back to fix everything to conform to standards, but they never seem to do so. If you learn nothing more from softwarephysics than the value in following standards to overcome the effects of the second law of thermodynamics and nonlinearity, as all living things do, you will find it well worth your effort. Too much of IT is hand-crafted and non-standard.
If It Ain’t Broke, Don’t Fix It!
Living things evolve through small incremental enhancements that always improve their survivability. Richard Dawkins calls this Climbing Mount Improbable (1996). In this book, Dawkins depicts survivability as a mountainous landscape, with foothills and valleys leading up the slope. Living things do not jump straight up the face of a steep cliff in this survivability terrain, instead, they follow a slow arduous upward path in their assent to improved survivability. They also do not descend into valleys of lower survivability, which might have an easier path to higher survivability on the other side of the valley, because living things cannot “foresee” the terrain of the survivability landscape lying ahead. Natural selection only lives for the moment and selects for advantageous mutations and against disadvantageous mutations at every point along the landscape. Consequently, living things can only move upwards in climbing mount improbable, or stand still if nothing else. There is no selective advantage to decreasing your chance of survival by descending into a valley of lower survivability. Now there is both good and bad in this strategy from an IT perspective. As an IT professional, you are not limited to this path of small incremental enhancements in your climb up mount improbable, because you are privy to an expanded view of the survivability terrain of software. This gives you a better view of the hills and valleys leading up the mountain than living things are privy to, but sometimes it is also advantageous to take the more limited view that living things have in formulating IT designs. So when somebody comes up with a brilliant enhancement in a meeting that sounds like a good idea, I frequently put the question to myself – “Would this enhancement naturally evolve in nature? What are the selective advantages of this approach? What are the selective disadvantages?“.
Here is a recent example, in WebSphere, there is a plugin-cfg.xml file that is installed on Apache webserver instances that tells Apache where to send WebSphere requests that it receives from browsers over the Internet. These requests are sent to physical WebSphere servers hosting WebSphere Applications installed in WebSphere Appservers. Now a typical physical Apache webserver might have 20 Apache instances serving up webpages for the many websites being hosted by the physical Apache webserver. Prior to WebSphere 6.0, we had just one communal plugin-cfg.xml file for all the Apache instances on a physical Apache webserver. The danger was that when we used WebSphere to regenerate the plugin-cfg.xml file for changes to Application A, there was a slight chance that it could mess up the plugin-cfg.xml file section for Application B. However, in 5 years of WebSphere administration, I do not recall a single instance of this actually happening. To overcome this non-existent problem, in WebSphere 6.0 IBM came up with an enhancement that allows for separate plugin-cfg.xml files for each of the 20 Apache instances we might currently have on an Apache webserver, providing complete isolation between the Applications being serviced by the Apache webserver. Now on the face of it, this sounded like a great idea to all, except to me. I immediately thought to myself, “Would this enhancement have a chance to evolve in nature? Would it be viewed as a positive mutation, enhancing survivability, or as a genetic disease to be ruthlessly eliminated from the gene pool?” My conclusion was that this enhancement would cause all sorts of problems because of the second law of thermodynamics and nonlinearity, with no offsetting advantages. My fear was that the developers who created our change tickets would forget to mention which of the 20 Apache instances we should map their WebSphere Applications to and that our Offshore team members doing the installs in the middle of the night, would occasionally get mixed up and accidentally copy the wrong plugin-cfg.xml file from one of the 20 directories storing plugin-cfg.xml files on the WebSphere Deployment Manager server to its corresponding directory on the 8 Apache webservers. You see, the WebSphere Deployment Manager server now has 20 directories storing plugin-cfg.xml files and each of the 8 Apache webservers also have 20 directories storing plugin-cfg.xml files, so the number of permutations of messing this up are huge. With WebSphere 5.0 there was only one plugin-cfg.xml file stored in one directory on the WebSphere Deployment Manager server and only one directory on each of the 8 Apache webservers storing the single plugin-cfg.xml file. This was pretty hard to mess up and it never happened over the course of five years. Now with the WebSphere 6.0 enhancement, we had 20 plugin-cfg.xml files to worry about on the WebSphere Deployment Manager server and 20 plugin-cfg.xml files on each of the 8 Apache webservers! Just do the math to come up with the ways you could mess that up! And sure enough, one pager cycle when I was Primary, we got hundreds of calls into our call center about people getting intermittent 404s when trying to login to our website. Naturally, I could not reproduce the problem. It turns out that our install team accidentally copied the wrong plugin-cfg.xml file into one of our 8 Apache webservers, causing a 1 in 8 chance of generating a 404. This was a very difficult problem to troubleshoot because I never had this problem when there was only one plugin-cfg.xml file used by all the Apache instances, so I never even suspected a bad plugin-cfg.xml file. Now, do I find fault with our install team for this mishap? Not in the least. Our install team does a marvelous job with the very difficult task of doing production installs. Too many times in IT we needlessly taunt the second law of thermodynamics when we tell people to avoid mistakes by simply “being more careful”. This is just setting people up for failure, like poking the second law of thermodynamics with a sharp stick. To alleviate this problem we now have a script that automatically pushes out the plugin-cfg.xml file from a menu. All you have to do is pick the correct plugin-cfg.xml file listed on the menu of 20 plugin-cfg.xml files. Even so, this requires a huge amount of intellectual energy to do correctly. The developers have to specify the correct plugin-cfg.xml file to regenerate for the Apache instance their Application uses on their change tickets and our Offshore team has to pick the correct plugin-cfg.xml file from the menu at install time. My contention is that this “enhancement” would be viewed in nature as a genetic disease, with a great deal of selection pressure against it because it consumes energy and resources, but provides no competitive survival advantage.
Follow the Lead of Bacteria and Viruses for Day-To-Day and Project Management Activities
As I pointed out in SoftwareBiology, prokaryotic bacteria are the epitome of good IT design, consequently, bacteria are found to exist under much harsher conditions and under a much wider range of conditions than multicellular organisms. We saw that bacteria block their genes to minimize I/O operations and do not load up their genomes with tons of junk DNA and introns, as do the “higher” forms of life. Similarly, viruses are also very good examples of lean IT architectural design, performing extraordinary feats of data processing at the molecular level with a minimum of structure. The simplicity, resourcefulness, and frugality of bacteria and viruses are surely to be admired from an IT perspective. So I strongly recommend that all IT professionals read a college textbook on microbiology to obtain a full appreciation of the very sophisticated data processing and project management techniques that bacteria and viruses have developed. There is much to be learned from them. So for the mundane day-to-day issues of IT, I frequently ask myself “What would a bacterium or virus do in this situation?”.
I also use bacteria and viruses as superb role models for good IT project management practices. An E. coli bacterium is a far more complicated data processing machine than any PC and can certainly outperform any PC on the market today (Figure 1). Yet an E. coli bacterium can build a clone of itself in 22 minutes from simple atoms using massively parallel project management processes. First, a self-replicating E. coli bacterium must use complex biosynthetic pathways to assemble the basic macromolecules of life, like amino acids, sugars, lipids, and DNA and RNA nucleotides, from carbon dioxide, water, and nitrogen for its clone. This code has to operate at transaction rates of billions of transactions per second to build the necessary feedstock for new cell wall and cell membrane material for the clone. The E. coli then proceeds to elongate by extending its cell wall and cell membrane by adding on additional proteins, phospholipids, and peptidoglycan to the existing structure. Eventually, the E. coli will split into two separate E. coli bacteria in a process called transverse fission, but before it can do that it must replicate the 5 million base pairs of DNA that define the 5,000 genes of its genome. The 5 million base pairs of DNA are supercoiled into the tiny E. coli bacterium, like stuffing a 30-foot string into a box that is ½ of an inch on a side. An E. coli can replicate DNA at the rate of about 1000 base pairs per second in each direction around its main loop of DNA from an initial starting point called the oriC. Surprisingly, humans do not have that many more genes than E. coli, we only have about 25,000 genes, but we require a full 9 months to self-replicate, so bacteria definitely have us beat on that score. Now at an overall rate of 2,000 base pairs per second, it takes about 40 minutes for an E. coli to replicate 5 million base pairs of DNA, and yet E. coli can self-replicate in only 22 minutes. How do they manage that feat of project management? Well as soon as the two new daughter loops of DNA begin to form, they immediately start to self-replicate too, so that by the time an E. coli fissions, it already has the DNA for the next generation well underway! E. coli are able to replicate their DNA with an error rate of about 1 error in every 100,000 base pairs. However, E. coli also have a DNA polymerase III enzyme that proofreads the recently replicated DNA and corrects about 99 out of each 100 errors so that E. coli can replicate with an overall error rate of about 1 error in every 10 million base pairs. Thus, when an E. coli bacterium replicates, there is only a 50% chance that its twin cell will contain even one error in the whole 5 million base pairs that define its genome!
Figure 1 – An E. coli bacterium (click to enlarge)
While all this DNA is being self-replicated, the E. coli is also busy forming huge numbers of about 3,000 proteins from amino acids for the enzymes that run the E. coli biosynthetic pathways and for the proteins that must be incorporated into the newly forming cell membrane material for its twin. To create the multiple proteins required to perform a particular task in one I/O operation, the E. coli DNA is transcribed to mRNA at a rate of about 50 bases per second by an enzyme protein called RNA polymerase (Figure 2). While the growing strip of mRNA, which contains multiple blocked genes for proteins, is being transcribed from the E. coli DNA, multiple ribosomes clamp onto the freshly generated mRNA at the same time and begin reading the mRNA I/O buffer and peeling off polypeptide chains of amino acids at the rate of 30 amino acids per second. You can actually see this all happen with the aid of an electron microscope, which shows a large number of ribosomes zipping along the mRNA and peeling off polypeptide chains of amino acids which later fold up into complex 3-dimensional proteins as the polypeptide chains seek a configuration that minimizes their free energy in accordance with the second law of thermodynamics.
Figure 2 – Multiple blocked genes are transcribed to mRNA by RNA polymerase and then a large number of ribosomes read the mRNA in parallel to form proteins by stringing together amino acids in the proper sequence. Individual proteins peel off as the ribosomes reach stop codons (end of file bytes) along the mRNA I/O buffer (click to enlarge)
Viruses are even more efficient project managers. Figure 3 shows the T4 virus, which preys upon E. coli bacteria. The T4 is one of the most complex viruses known and is about 900 atoms wide and 2,000 atoms long and looks very much like the Lunar Landing Module of the Apollo missions and performs a very similar function. The head, collar, sheath, base plate, and tail fibers of the T4 are composed of several thousand individual protein subunits held together by the electromagnetic force. The head contains the DNA for 200 T4 genes encoded on 168,800 base pairs, which is far more many genes than most viruses have, the smallest of which contain only about 10 genes. When a T4 lands upon the surface of an E. coli bacterium, the T4 tail fibers grip onto specific molecules in the outer cell envelope of the E. coli. The contractile sheath of the T4 consists of 24 protein rings, but when the T4 lands on an E. coli, the base plate is unplugged, and the 24 rings contract into 12 rings, which injects the T4 DNA into the E. coli like a syringe. Within one minute of the T4 DNA being injected into the E. coli, the production of E. coli mRNA for E. coli proteins ceases because the E. coli RNA polymerase is actually more strongly attracted to the promoters for the T4 genes on the T4 DNA than for its own DNA! In less than 2 minutes, the E. coli RNA polymerase begins transcribing the T4 DNA of specific T4 genes to produce early T4 proteins that take over the biosynthetic processes of the E. coli bacterium. Within 5 minutes of infection, these T4 proteins begin to break down the 5 million base pairs of E. coli DNA into nucleotides that can be reused to make DNA for new T4 viruses. In less than 10 minutes, under the direction of the T4 DNA, the E. coli then begins making about 50 different enzymes that can replicate T4 DNA about 10 times faster than E. coli DNA, but with a higher error rate. So now the E. coli bacterium starts to make T4 DNA at a rate of 10,000 base pairs per second, yielding one T4 DNA strand every 17 seconds. This is also done in parallel at multiple sites to create the DNA for 100 – 300 T4 viruses. At the same time as all this T4 DNA is being generated, the E. coli is also manufacturing the proteins for the T4 heads based upon the instructions in the T4 genes. As each T4 head is completed, it is stuffed with a T4 DNA strand. Next, T4 DNA is transcribed into mRNA for the tail proteins. The base plate is formed first and the contractile sheath is assembled upon the base plate which is then capped. The completed head and tail assemblies are then welded together to form a completed T4 virus. A T4 gene then creates a protein that can eat through the E. coli cell membrane and wall. This forms a hole in the E. coli bacterium, and about 25 minutes after infection, 100 – 300 T4 viruses emerge from the now dead E. coli bacterium ready to infect other E. coli.
Figure 3 – A T4 virus Lunar Landing Module (click to enlarge)
While on the subject of viruses, it should be noted that viruses are marvelous DNA survival machines and very good examples of self-replicating information that come in many sizes, shapes, and configurations. Some have complex structure, like the T4, while others, like polio and cold viruses, come in a simple spherically shaped capsid protein shell like the head of a T4. The HIV virus is an example of a complex virus that has a capsid protein shell surrounded by a second protein shell, which in turn, is surrounded by a phospholipid membrane with embedded proteins, like the surface of a normal human cell. Viruses can contain single-stranded DNA or double-stranded DNA in the form of linear strands or a circular loop. They also can contain single or double-stranded RNA. A virus may contain tens to hundreds of genes, and since they are totally dependent upon full-fledged cells to replicate, viruses have evolved to replicate quickly with less fidelity than normal cells. Viruses are in a constant battle with normal cells because, for the most part, they are purely parasitic forms of DNA or RNA – just mindless forms of self-replicating information. Normal cells have evolved a number of strategies to combat the viruses, like altering the proteins in their outer cell membranes so that the viruses cannot attach to their cell membranes. So viruses tend to replicate DNA and RNA with less fidelity to allow favorable mutations to arise more easily to combat the defense mechanisms of normal cells. Because viruses are constantly evolving new survival strategies, they evolve more quickly than bacteria or other life forms, and that is why new strains of cold and flu viruses are constantly emerging. Some viruses have even evolved to form a parasitic/symbiotic relationship with their hosts. For example, certain viruses that infect bacteria have become lysogenic temperate viruses. A lysogenic virus does not usually kill its host bacterium. Instead, the injected viral DNA splices itself into the bacterium’s main loop of bacterial DNA. Thus, each time the bacterium replicates, it passes along the viral DNA to its descendants. After all, the name of the game for self-replicating information is to find a way to replicate; it really does not matter how that is achieved. Some of the genes in the viral DNA that is now part of the bacterium’s main loop of DNA even alter the proteins in the host bacterium’s outer cell membrane to make it harder for other viruses to attach to the infected bacterium! Thus, a bacterium infected by a lysogenic virus gains some immunity to other viruses, and the bacterium and viral DNA are truly in a parasitic/symbiotic relationship like that explored in Software Symbiogenesis. However, a lysogenic virus still needs to replicate on its own once in a while, otherwise it would lose its identity and just become part of a new strain of bacteria. So about one time in a thousand, the infected bacterium will go through the normal lytic process to generate hundreds of viruses that escape to infect other bacteria, like a T4 virus does.
Because viruses cannot replicate themselves without the aid of normal cells, most biologists do not consider viruses to be alive. There is also some controversy as to how the viruses originated. Most biologists think that viruses are escaped genes – self-replicating DNA or RNA that were once part of a normal cell, but which have developed their own little spaceships to explore the biosphere with. Others believe that viruses are active fossils of self-replicating information from a time before there was true life on Earth and that viruses evolved from precursors of true living cells. The Equivalence Conjecture of Softwarephysics might be of help here. In the Software Universe, we definitely know that computer viruses arose in the 1980s after the development of operating systems and application software. Many computer viruses are lysogenic, in that they splice themselves into the executable file of application software and are launched each time the application is executed, and they look for other hosts to infect with each application launch. Others just look for other executables on a PC to infect and rely on those executables being accessed by other PCs on a network. However, I don’t think many computer viruses form symbiotic relationships with their hosts by making applications even better - software vendors call those upgrades and charge dearly for them.
I frequently try to follow the superb project management techniques of bacteria and viruses when doing IT project management work, especially the use of massively parallel repeatable processes. For example, in the late 1990s, I spent about three years on Amoco’s Y2K project. I was in charge of coordinating the remediation of about 1/3 of Amoco’s applications, about 1500 applications. The overall project manager of this effort was constantly assigning us impossible tasks, like “Please review all of your remediation plans and report back next week on those that might be behind schedule”. Just do the math. If you spent just one hour reviewing each of 1500 remediation plans, that would come to 1500 hours. For a 40 hour work week that would come to 37.5 weeks just to do a cursory review of all 1500 remediation plans! The way we finally worked through issues like this was to form a hierarchy of coordinators all using the same repeatable processes. I had 8 sub-coordinators and each of them had a sub-coordinator in each Application Development group, and the sub-coordinators in each Application Development group were responsible for the Y2K remediation of all the applications the group supported. As a member of the top tier of Y2K coordinators, I spent most of my time putting together repeatable processes for managing the Y2K remediation of the applications that could be run in parallel on all 1500 applications.
We created a hermetically sealed lab for the distributed applications running on Unix and Windows servers and an LPAR on our mainframes for Y2K testing. The first step was to determine which applications needed Y2K remediation and to create remediation plans for those that did. Luckily for me, as a former geophysicist, I had all of the exploration and production applications, many of which did not do date processing and did not require Y2K remediation. However, I also had the Amoco corporate applications which took data from the Amoco subsidiaries and these applications were very rich in date processing, so I still had plenty of work to do. The determination of Y2K readiness and the production of remediation plans was done in a more or less parallel manner by all of the sub-coordinators. We had some software that scanned for date processing that helped with the analysis, and we created a database and some software to create and store all of the remediation plans. This allowed us to keep track of the overall progress of the Y2K remediations and to manage the whole process. We then scheduled each application that needed Y2K remediation for a “flight” in the Y2K lab. The system clocks on the Unix and Windows servers and the mainframe LPAR were then cycled through about 25 critical dates over a one-week “flight”, starting with the date 09/09/1999 (the dreaded date = “9999” problem) and continuing on with 12/31/1999, 01/01/2000, … etc. Production test data was allowed into the hermetically sealed Y2K lab, but no data was allowed to escape it, for fear of contaminating our current 20th-century production processing with 21st-century data. So for your next IT project that calls for the migration of all your applications to a new operating system release or a new version of Oracle or some other global infrastructural change, take a tip from bacteria and viruses and use a project management approach based upon repeatable parallel processes and you will make your deadline for sure.
Focus on Implementation and Change Management Processes
It is also useful to follow the lead of bacteria and viruses when it comes to IT implementation processes and change management activities. When I transitioned from geophysics into IT in 1979, there were no Change Management groups, no DBAs, no UAT testers, no IT Security, no IT Project Management department, and we didn’t even have IT! I was in the ISD (Information Services Department), and I was a programmer, not a developer, and we ruled the day because we did it all. Yes, we had to deal with some meddling from those pesky systems analysts with their freshly minted MBA degrees but no programming experience, but thankfully, they were usually busy with preparing user requirement documents of a dubious nature and did not get into our way too often. ISD had two sections - computer systems and manual systems. The people in manual systems worked on the workflows for manual systems with the Forms Design department, while the computer systems people programmed COBOL, PL/I, or FORTRAN code for the IBM MVS/TSO mainframes running the OS/370 operating system. Luckily for me, I knew some FORTRAN and ended up in the computer systems section of ISD, because for some reason, designing paper forms all day long did not exactly appeal to me. We created systems in those days, not applications, and nearly all of them were batch. We coded up and tested individual programs that were run in sequence, one after the other, in a job stream controlled by JCL or a cataloged procedure. To implement these systems all we had to do was fill out a 3-part carbon paper form for the Data Management clerks – they got one copy, we got one copy, and somebody else must have gotten the third copy, but I never found out who. The form simply told the Data Management clerks which load modules to move from my development PDS (partitioned dataset) to my production PDS and how to move the cataloged procedures from my development proclib to the production proclib. That was it. Systems were pretty simple back then and there was no change management.
This worked great until the Distributed Computing Revolution hit in the early 1990s. Then computer systems became applications, and they were spread over a large number of shared computing resources – PCs, Unix servers, Windows servers and mainframes, and the old implementation model no longer worked. Suddenly, IT had to come up with change management and implementation processes for the new complicated distributed architecture. But unfortunately, the old mindset of Application Development (programmers) ruling the day still persisted through this revolution, even though the IT world had totally changed. And because the three laws of software mayhem never went away, the Application Development Life Cycle (ADLC) on the distributed platform always tended to get behind schedule, so that the last step in the life cycle, the implementation step, got compressed into an IT after-thought along with change management. Implementers were still on the bottom of the IT totem pole, like the Data Management clerks that I dealt with in the 1980s, and often times had to deal with half-baked implementation plans crammed through the new change management processes at the last minute.
I have found that different IT shops have matured to various degrees with change management procedures and the implementation step of the ADLC, with some doing better than others, but as a whole, IT could certainly improve with these vital processes. So I would like to propose a biological approach to change management processes and the implementation step of the ADLC. As we saw above, when a T4 virus lands upon an E. coli bacterium, it has a detailed implementation plan of exactly what to do and when with each step rigorously detailed. The net result is that 25 minutes after landing upon an E. coli bacterium, the T4 has produced 100 -300 T4 viruses and has flawlessly manipulated the reactions of a trillion trillion molecules in the process. Think of it in another way. In medicine, surgeons are at the top of the medical totem pole. Before you go into surgery, you will see your family GP and probably an internist, cardiologist, or oncologist who will help with the diagnosis of your problem by ordering a large number of tests and perhaps engaging the services of a radiologist for a CAT scan or MRI, and maybe a pathologist to read some biopsy slides. When you go into the OR, an anesthesiologist will put you under and keep you alive during the procedure, but it will be the surgeon that either cures you or kills you. In medicine, they don’t like to find out halfway through an operation that the artificial heart valve is the wrong size or that they ran out of blood for the patient. In medicine, the implementation step is key and the surgeon, or implementer, is the Captain of the ship and is well prepared and fully supported by the rest of the medical community. Last-minute shoot-from-the-hip efforts are not tolerated for long. Similarly, IT needs to refocus some energy into the vital process of change management and the implementation step of the ADLC. After all, like a surgical patient, end-users do not experience the beneficial or ill effects of software until it is implemented.
Follow the Lead of Multicellular Organisms and the Biosphere for Architectural Issues
For higher level IT issues, look to the superb organization found in multicellular organisms and the biosphere. For example, we are currently going through the SOA – Service Oriented Architecture revolution in IT. With SOA, we develop a large number of common services, like looking up the current status of a customer, which can then be called by any number of applications, rather than have each application individually code the same identical functionality. As we saw in SoftwareBiology, SOA is just the IT implementation of the dramatic eruption of multicellular architecture during the Cambrian Explosion 541 million years ago. Consider the plight of a single, lonely, aerobic bacterium which is challenged to find its own sources of food, water, oxygen, and warmth and must also find an environment in which it can dump its wastes without poisoning its immediate surroundings, and do all this while it tries to avoid all the dangers of a hostile microbial world. Contrast that with the relatively fat and easy life of the 100 trillion cell instances in your body that find themselves bathed in all the food, water, oxygen, and warmth they could desire, without the least worry about dumping their wastes into their immediate environments because their wastes are briskly flushed away, and without the least worry of being taken out to lunch by a predator. The poor little bacterium must have code that handles all these difficult situations, while the cells in a multicellular organism just rely on the services of other cell instances residing in SOA service machines, or organs, known as hearts, lungs, intestines, livers, kidneys and spleens to handle all these common services. In Software Symbiogenesis and Self-Replicating Information, we saw how the biosphere has taken SOA to an even higher level. Not only do the cells in a multicellular organism rely upon the services of cells within the organs of its body, they can also rely upon the services of cells in other bodies via parasitic/symbiotic relationships between organisms. We are beginning to see this in IT too, as companies begin to expose services to other companies over the Internet to allow B-to-B applications to form symbiotic relationships between businesses in a supply chain.
I became convinced of the value of SOA many years ago at United Airlines before SOA had even appeared on the IT scene. At the time, I was supporting the middleware for www.united.com running on Tuxedo. Through a process of innovation and natural selection, the middleware group ended up writing a large number of Tuxedo services to access things like customer data from a series of databases and reservation data stored in the Apollo reservation system to support www.united.com. We then opened up these Tuxedo services for other internal applications at United to use via a JOLT call from their Java applications. Over a period of a year or two, we accidentally evolved a pretty sophisticated SOA architecture. This SOA architecture was put to the test one day when my boss got a call from our CIO. It turns out that our marketing department had published a “Fly Three, Fly Free” campaign in hundreds of newspapers that day. The campaign explained that if you flew three flights with United in any given month, you were then eligible to fly free to any destination within the continental United States. All you had to do was to register for the campaign to obtain your flight benefit. Now that was the problem. Our marketing department had forgotten to tell IT about the new campaign, and in the newspaper ads, it stated that the promotion was going into effect that day at 12:00 midnight! So we had 15 hours to design, develop, test, and implement an application to be used by our call centers and that could also be run from www.united.com. We immediately formed a number of crash workgroups in applications development, database, QA testing, and call center training to field this application as quickly as possible by working in parallel as much as possible. And because we could sew together an application quickly by calling our already existing SOA Tuxedo services, we actually made the 15-hour deadline! After that experience, I was totally sold on the idea of SOA, before SOA even existed.
Let Softwarephysics Guide Your Career Path
SOA has the advantage of reducing the amount of redundant code that a corporation has to maintain and allows developers to quickly throw together new Applications because they can just assemble them from a collection of existing components or services. The problem that SOA presents is governance - who decides how and when to change components? SOA can also be a problem for Operations when troubleshooting problems because many applications draw upon the same services, and a bug in one service can impact many applications. So is SOA a good thing or a bad thing? And how do you decide?
Well, there was this same controversy about object-oriented programming in the early 1990s. Was object-oriented programming a good thing or a bad thing? And was it just a flash in the pan, or something that would catch on? There is a lot of hype in IT, and you can easily get misdirected down the wrong architectural path. For example, in the early 1980s, they told us to start looking for a different job because IT would soon be vanishing. You see, in the early 1980s, the theory was that 4GL languages (4th Generation Languages), like Mark IV and Focus, would soon allow end-users to simply write their own software, and the Japanese were also working on a 4th Generation Computer, due to be completed by 1990, that would be based upon an operating system using Artificial Intelligence. End-users would interact with this new operating system like the folks in 2001 - A Space Odyssey, with no need for pesky IT people. But none of that ever happened! So in the early 1990s, the COBOL/CICS/DB2 mainframe folks had a dim view of object-oriented languages like C++ because they thought they were just another flash in the pan. There was also a lot of FUD (Fear, Uncertainty, and Doubt) in the early 1990s because of the impending architectural change to a distributed computing platform which made matters even more confusing. We saw folks throwing together LANs with cheap PCs, and then there were those nasty Unix people bringing in Unix servers to replace the mainframes too. Mainframes were supposed to be gone by 1995, and IBM nearly did go bankrupt in those days. So maybe Unix and C++ might be something good to learn - or maybe not?
So how do you make sense of all this? How do you make good IT decisions about your career path when IT architectural changes seem to be happening, but there is all this hype? Fortunately, I had softwarephysics back in the early 1990s to help me make decisions. Based upon softwarephysics, I taught myself Unix, C++ and Java (1995) when it came out because softwarephysics told me that object-oriented programming was a keeper and would have a big impact on IT. Softwarephysics also predicts that SOA is the way to go too. Softwarephysics claims that object-oriented programming and SOA are really just implementations of multicellular organization in software. An object instance is just a cell. The human body has 210 cell-types or Classes. Each of the 100 trillion cells in your body is an object instance of one of these 210 Classes. Each cell is isolated by a cell membrane that protects it from other cells so that other cells cannot directly change the cell's "data". In object-oriented languages, this is called encapsulation. Each cell contains many internal methods(), used by the cell to conduct biological operations. Each cell also has a set of public or exposed methods() that can be called by other cells, via the secretion of organic molecules, that bind to receptors on the cell membrane and induce the cell to perform biological processes. The cells in your body also use the object-oriented concepts of inheritance and polymorphism. The 100 trillion cell instances in your body use the SOA services of other cell instances, like the cell instances in your lungs, liver, kidneys, heart and intestines. These organs, or service machines, provide your cell instances with oxygen, food, and water, and also dispose of the wastes they excrete. So given the success of the multicellular architecture found in the biosphere, softwarephysics predicts that object-oriented programming and SOA will also be successful and worthy of investing some time in learning.
Conclusion
As you can see, softwarephysics is not a magic bullet to cure all of your IT woes. It is really more of a way to think about software. Because it provides an effective theory of software behavior, softwarephysics can be a very robust and flexible tool in your IT arsenal. All you have to do is use your imagination!
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
No comments:
Post a Comment