Sunday, July 22, 2007

SoftwarePhysics Revisited

Since it appears that nobody has solved the fundamental problem of software outlined last year in my original blog at:

http://softwarephysics.blogspot.com/2006/07/softwarephysics.html

I thought there would be no harm in folks taking another look at softwarephysics. I personally have been using softwarephysics on a daily basis for over 25 years to help make decisions about software, and to help me cope with the daily mayhem of life in IT, and it might help you too.

For those of you already familiar with softwarephysics, I have a revised version of SoftwarePhysics 101 – The Physics of Cyberspacetime, which is now available on Google Drive. Please note that some of the formulas do not render properly, especially exponents which do not display as superscripts, so please use your imagination.

Part1 - Part 1 of the original PowerPoint document.
Part 2
- Part 2 of the original PowerPoint document.
Entropy – A spreadsheet referenced in Part 1
BSDE
– A 1989 document describing how to use BSDE - the Bionic Systems Development Environment - to grow applications from genes and embryos within the maternal BSDE software.

In the new edition, I have expanded on how lines of code can be thought of as organic molecules composed of atoms (characters) in fixed quantum states, and beefed up the section on quantum mechanics in general. I also expanded the section covering Einstein's Special Theory of Relativity in relation to causality and the flow of information in the universe. As a supplemental reading, you can find an excellent treatment of the Special Theory of Relativity with very little math, at professor John D. Norton’s course HPS 0410 Einstein for Everyone at:

http://www.pitt.edu/~jdnorton/teaching/HPS_0410/chapters/Special_relativity_rel_sim/index.html

Be sure to investigate the animated graphic on the Relativity of Simultaneity towards the middle of the webpage, which is far more illuminating than my static slide. Quantum mechanics and relativity are both difficult topics, and I hope the additional slides help clarify these ideas. There have been many other minor changes and additions too, that might warrant another look. Again, this course was designed to be given as a series of one hour seminars over an extended period of time to keep the lethal effects of physics in large doses down to a minimum. When the first director of Fermilab was asked by the FBI what he would do if Fermilab was stormed by an angry mob of anti-war protestors, he responded with "Don't worry, we have a devastating physics lecture under lock and key in our armory for just such an occasion; thank God we have never had to use it!".

For those of you not familiar with softwarephysics, please consider the following thought experiment. Sometime in the spring of 2008, CERN hopes to crank up its new 14 TEV LHC accelerator which will supersede Fermilab's record breaking 4 TEV accelerator. Imagine that you are a senior physicist on the LHC team that morning and you hear a commotion down the hall. One of your postdocs sticks her head into your office doorway and says, "Hey boss, we finally got the beams up to 14 TEV! We did not find the Higgs boson yet, but we found something even stranger. Nobody has ever seen anything like it before! We decided to call it "software"." I had just such an Alice in Wonderland experience in 1979 when I made a career change and transitioned from being a geophysicist into being a professional IT person. Suddenly one Monday morning, I found myself in alien territory on the floor of Amoco's IT department surrounded by all these strange IT people. They seemed really good at weird complex abstract thought, much more like physicists than the general public at large for sure, but they were always in such a hurry! Every once in a while, I would grab one of them by the scruff of the neck and ask, "So what is this software stuff made of? What are its physical properties? How does it behave? Does it follow physical laws?". The answer was always, "Sorry. Don't have time to think about that now, I have a deadline to make!". That's when I decided to become a softwarephysicist. Since all I knew was physics and a little FORTRAN that I used for modeling geophysical observations, I needed something to help me find my bearings in this new profession. I guess people always gravitate back to what they are comfortable with when placed into an awkward position. I knew a guy who moved from Chicago to the western suburbs when he was a teenager. Whenever he had to go somewhere in the Chicago area, the first thing he did was to drive back to Chicago. I did basically the same thing when I first landed in Amoco’s IT department. The first thing I did was to envision software as a virtual substance. Then all I had to do was follow the normal drill of theoretical physics - make some field observations of software behavior, formulate a model that explained that behavior, and then test the model as best I could.

Software is indeed a strange substance. It can be as hard as nails and as fast as lightning most of the day, and then suddenly it goes through a phase change and becomes a viscous tar-like, goopy, sludge that is as slow as molasses. It can be incredibly stable for many months at a time, and then with a very tiny alteration, it begins to behave like nitroglycerin on a hot summer day. Why does it do that? Is there anything we can do about it? These are some of the questions that softwarephysics tries to answer. In truth, all IT people are really softwarephysicists already. They just don't know it yet. And that goes for nearly the entire population of the modern world too. I get several phone calls per week from my wife concerning cybersludge, and I am sure that you get desperate pleas from friends and relatives too. If software weren't so useful, nobody would put up with the aggravation.

My immediate impression in 1979 was that the software side of computer science seemed to be a little isolated without much interaction with the other sciences, while out of necessity, the hardware side of computer science was heavily dependent upon physics, electrical engineering, and the material sciences. Since the software side of computer science was relatively new at the time, this was quiet understandable. So I decided that it would make sense to throw all the physics, chemistry, and biology I could muster at the problem of commercial software development and support to make my life easier as a professional IT person. I called the approach softwarephysics. I figured if you could apply physics to geology, why not apply physics to software? The basic idea was that many concepts in physics suggested to me that the IT community had accidentally created a pretty decent computer simulation of the physical universe, and that I could use this simulation in reverse to better understand the behavior of commercial software. This reverse simulation also suggested that a biological approach to software development and support would be a better approach to take than the current traditional IT methodologies.

In 1987, Chris Langton was at the Los Alamos National Laboratory. Just as the web browser, HTML, and the World-Wide Web were invented by Tim Berners-Lee in 1989 in his spare time at CERN, Chris Langton came up with the idea of Artificial Life in his spare time while working at Los Alamos. The basic idea was that biologists could learn a lot about living things by creating artificial simulations of living things with software. Following a few conferences on Artificial Life at Los Alamos, there was a flurry of excitement in many computer science and biology departments at leading universities and research institutes throughout the world in the early 1990s. As with Artificial Intelligence, this initial excitement dropped off a bit as reality set in. However, about 10 years ago the Artificial Life people in academia came to the realization that they could use this simulation approach in reverse too. They figured IT people could learn how to build and operate better software by using concepts from biology. In the U.S., this became known as "biologically inspired computing" and in the U.K. they call it "natural computing". About 5 years ago a dozen or so universities began to offer graduate and undergraduate computer science courses in "biologically inspired computing" and "natural computing". You can find information about these courses and professional conferences on these topics by Googling for "biologically inspired computing" and "natural computing" on the Internet.

So the Artificial Life people have caught onto the biological aspects of softwarephysics, but they still have not caught onto the aspects of softwarephysics based upon physics and biochemistry to a great extent yet. And as far as I can tell, the first successful commercial application of these ideas, aside from some early commercial applications of genetic algorithms, was in 1985 when I developed the BSDE (Bionic Systems Development Environment) tool at Amoco.

Because softwarephysics is still a bit unconventional, to say the least, softwarephysics has been stuck at the first stage of the life-cycle for all new theories for nearly 30 years:

1. First it is ignored
2. Then it is wrong
3. Then it is obvious
4. Then somebody else thought of it 20 years earlier!

You know you are treading on new ground when even the Artificial Life folks think that your ideas are rather exotic! So this is your chance to get in on the ground floor. You can be the first softwarephysicist in your cube farm if you act now!

Comments are welcome at scj333@sbcglobal.net

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

Regards,
Steve Johnston

No comments: