Our pastor and my good friend Tom retires at the end of this month. Last Sunday he spoke about when he was eight years old and some friends asked him what he wanted to be when he grew up. He said “a minister,” but then he quickly covered himself and said “or a garbage truck driver.” Those that know his life story understand how that single idea stayed with him, resulting in his ultimate graduation from Denver Seminary and leadership of Grace Evangelical Free Church here in Longmont.
It is a lucky thing when young people know from the start what they want to be in life. Even with that destination in mind, the journey can have twists and turns. My son, Mark, has always been interested in food and cooking, and he’s worked in food service for half his life so far. But he’s also worked in technology as a printer starting his apprenticeship under his Uncle Chuck in Alaska and working for several printing businesses in Boulder and Denver. He worked in digital printing at IBM and Lexmark and currently works at my old company, Ricoh Production Printing in Boulder. (IBM Printing Systems was sold to Ricoh and was called InfoPrint Solutions before becoming a division of Ricoh.) With printing paying the bills, he is currently in college studying nutrition and pursuing that life-long goal.
My son, Mike, got a degree in auto mechanics, but worked most of his life as a house painter. Recently he’s branched out into other areas of construction and even handyman jobs like shoveling snow and trimming tree branches. Now he is considering taxidermy. He is still working on his goals.
I always knew what I wanted to do from about eight years old on: I wanted to be a scientist. The exact technical area changed over time, but the basic concept remained.
At first I wanted to be an Astronomer or a physicist (Einstein’s theories enthralled me), then an electronics … something. At one point my parents gave me a record recorder. It had a microphone and blank records and some attachments you added to the turntable and you could cut records. I was 8 or 10 at the time. Instead of recording music, I recorded a lecture on why a rocket could not exceed the speed of light. It included an explanation of Einstein’s theory of mass increase as velocity approached light speed, and I sure wish I had that recording now!
After that, I decided I would become a Geologist. A professor from Stanford University spent the summer at our motel and later sent me a college geology text book which bent my path for a time. I dabbled in chemistry and biology, creating a laboratory in my basement bedroom, and my dad bought me an expensive microscope from Edmunds Scientific. I built electronic projects, owned a couple of short wave radios, and did amateur radio experiments, all before high school.
I got a little sidetracked during high school with my involvement in motorcycles and wine, women, and song — although not necessarily in that order. I played around with music, but the talent was lacking. I even went to the School of Mines in Butte, Montana, after high school — a flash-back to the geology book from the Stanford professor. That was a mistake. I played a lot of music and drank a lot of beer in my one year at Mines, and then it was into the labor market.
I worked on a rock drilling rig prospecting for gold in the nearby mountains, for the Bureau of Land Management fighting forest fires, worked at two different lumber mills in White Sulphur Springs and Libby, Montana, worked for Anaconda Copper company in their smelter at Great Falls, Montana, and continued to pursue musical interests until Uncle Sam invited me to join his yacht club. (That one sentence made a pretty respectable paragraph, don’t you think?)
I got back on track in the Navy, electronics training there, and worked as a technician after I got out. Got my First Class FCC Commercial license, worked in radio and TV, worked as a designer at an aero space company, and taught electronics at a technical school in Denver. I got the engineering degree that was my ultimate goal from Metropolitan State College. (The “at Denver” was added to the name later.)
After seven years of attending Metro at night, I still had some VA benefits left, so I changed track and studied math and physics at CU earning a Master’s degree. Continuing the electronics engineering direction would have been logical, but I wanted more of the “why” after learning so much of the “how.” Electronics still interested me, but I wanted to go deeper into the understanding of things. Math and physics served that purpose. I taught night classes at Metro during those years, and was hired on by IBM as an electronics engineer.
I had a friend and mentor at the time named Joe Clark. He was the technical director at the electronics school I taught at. He pursued a degree in distributed studies, which meant basically three minors: math, physics, and philosophy. We had many long discussions about the intersection of those three disciplines, and I had a deep interest in topics such as the history of technology and epistemology, which is the study of how we learn and what is the composition of knowledge.
I only took one philosophy class in college, although I enjoyed the class very much and the instructor was very special. I was voted by the class "outstanding philosophy student." Always a great honor to be recognized by your peers. I’m a voracious reader, and I’ve read thousands of books in my lifetime. I read about philosophy, and I expanded my knowledge of history and literature through self-study. I also encountered several schools of philosophy in my deep math studies. The theories of knowledge and education interested me both philosophically and from a practical perspective. As a teacher, I was most interested in theories of knowledge and how to train, teach, and impart practical and theoretical knowledge, as well as how to measure success of that teaching.
I did accomplish my childhood goal when IBM gave me the title of “Associate Engineer/Scientist.” I can’t say for sure if that was due to my math and physics studies or it was just a general title that IBM gave some of their technical staff. I primarily worked as an engineer designing test systems and developing digital recording products. I worked as a manufacturing engineer supporting the development and production of diskette drives and magnetic recording heads. I did some programming as part of that job and also some statistical analysis.
I continued teaching, working on a project for IBM where I taught the use of personal computers (Apple II) to a local school district and teaching the use of personal computers (IBM PC) to employees in Boulder. That eventually led to a full-time job with IBM Education and Training, and I spent fourteen years traveling all over the U.S. and even outside the country teaching basic and advanced programming techniques, testing, and project management.
Although my childhood goal had been to be a scientist, I think my gifts and skills led me to teach. In some sense, all the technical topics I learned were just subjects for me to teach. IBM sent me off to various colleges for short courses on teaching, and I attended classes at Colorado State, Vanderbilt, and Harvard. I taught myself how to publish documents and books electronically, and wrote two text books that IBM used in their classes with thousands of students.
So here I was teaching programming and software engineering, yet my degrees were in electronics engineering, math, and physics. I attended a special IBM training program called the University Level Computer Science Curriculum which consisted of 25, one-week long classes taught in IBM classrooms by university faculty. So I did have formal programmer education to go with my self-taught skills, but no software degree.
Eventually I left IBM Education and started working for the IBM Printing Systems Division. Now that I wasn’t traveling all the time,I could go back to school. It had always been my goal to obtain a Ph.D. and garner the title of “Doctor.”
I considered various Ph.D. programs from EE to Education, but couldn’t decide. My job had morphed from hardware to teaching to software, and so I decided to get a second Master’s in Computer Science. I was teaching and leading software engineers; I had the title Senior Software Engineer title, but I didn't really think I was an Software Engineer since I lacked the specific degree. So, it was back to school. I couldn't get a Ph.D. in Software Engineering since I didn’t have the basic credentials. Four years later, spending evenings and weekends, I got my Master’s in Computer Science from the University of Denver, and now I’m ready for that Ph.D. I’m currently enrolled in a couple of online courses at Stanford University (strange return to the source — remember the geology text book), but they are just supplemental to what I already know, and not part of a degree program. I don’t know if I’ll ever get that Ph.D. That is a decision I’ll defer to another time.
Engineering, Science, and Software
After this lengthy introduction, I want to talk about a perspective of science I’ve gained by having three degrees: 1) engineering, 2) science, and 3) software, as well the philosophical perspective of knowledge I’ve gained from these various viewpoints. There are many similarities and differences between these three areas of study. There is considerable overlap and synergy, but there are also big differences in approach and the body of knowledge of the three disciplines.
Engineering is all about the rules … and they are very specific and … well … specified. Engineering is a discipline based on science, so it can never violate the laws of nature — self consistency exists at nearly all scales. The scientific areas of math and physics are similar regarding rules and formulas. (There might be some inconsistency in the domain of sub-atomic particles and quantum theory … not so sure about that!) My study of physics and math just took me deeper into these rules, and I even learned about where the rules did not apply.
The Heisenberg uncertainty principle states a fundamental limit on the accuracy with which certain pairs of physical properties of a particle, such as position and momentum, can be simultaneously known. In layman's terms, the more precisely one property is measured, the less precisely the other can be controlled, determined, or known.
In math, Gödel's Incompleteness Theorems establish inherent limitations on all but the most trivial axiomatic systems capable of doing arithmetic. The theorems, proven by Kurt Gödel in 1931, are important both in mathematical logic and in the philosophy of mathematics. He proved that, in any self-consistent, mathematical system, there will be “truths” that can’t be expressed without going outside the system into what is called a meta-system. Basically he proved that there are limits to even the beautiful thought structures that make up pure mathematics.
From my earliest Navy training (actually the Calibration School training at Lowry Air Force Base, Denver), I had learned of the limitations of electronic instruments. There were issues of accuracy and circuit loading. Heisenberg demonstrated that, regardless of the perfection of the measuring instruments, God actually hides some level of detail, and that hidden portion has led to some very interesting suppositions and a hope of power sources from the very fabric of the universe. Mathematics, on the other hand, seems to be crafted from pure thought stuff, and it was supposed before Gödel that there were no limitations other than the power of human imaginations to plumb the depths — no fenced off area that trespassing was forbidden.
Heisenberg showed limits to physical science and Gödel showed limits to mathematical science. Philosophy is obviously limited, and we all know there is no consistency to economics or political science or any of the other modern disciplines that have added “engineering” to their names without actually adding rigor and fundamental principles.
Religion claims an absolute, yet there are hundreds of faiths. Even within the Christian religion, there is no exact interpretation, but rather a lot of discourse and disagreement among denominations.
But let’s return to the three disciplines I’ve described, engineering, math, and computer science. The question to examine: is computer science an engineering discipline? Is it really Software Engineering?
Think about how the term “engineering” has expanded in common use. Some of it represents the respect that modern society has for engineering, although there have been a few spectacular failures from the unsinkable Titanic to the Tacoma Narrows Bridge failure. In general, however, engineering has gained a respect in the twentieth century that the name has been added to less technical occupations from custodial engineer for janitor to Wall Street’s financial engineering that gave us great products such as financial derivatives and high speed, automated trading that triggered our current economic and political malaise.
Consider that software engineering is inherently an information-based discipline, so the laws of imagination are much more applicable and laws of nature much more flexible. That sets Computer Science apart from most other sciences and begs the question “is Software Engineering no more a true engineering discipline than financial engineering?”
In 1948, Claude Shannon wrote an epic paper on communication theory called “A Mathematical Theory of Communications” which was published in the Bell Systems Technical Journal. He codified what the ancient philosophers had struggled to understand about information content and the limitations of that information.
Shannon’s work applied equally to electronics communications and digital circuit design.
Software developers and programmers have a right to laugh at those that think that by merely adding the word “engineering” to their tasks, they can somehow elevate them to something infallible. What they miss is that the art of programming and software development is a lot more human communication than it is engineering. And, regardless of Shannon’s discovery, communication is still something that has to do more with human nature than with mathematical rules and formulas.
I’m reminded of the famous relationship: "data —> information —> knowledge —> wisdom." Some map the decades of computer advancements from data processing in the ‘50s to knowledge engineering in the ‘90s (there’s that adding the “E” word again). But from what comes wisdom? For that, we must return to philosophy and religion.
Getting back to my education theme: Software Engineering is perplexing because it exists at the intersection of physics, mathematics, and information — the first two, hard sciences with their own laws. Physics is central to software because electricity, the movement of electrons — drives on or off switching of bits and signaling from one part of the system to another a device’s status or condition. Mathematics is central to software because the meaning of bit-patterns must remain static and unchanging. The bit-pattern for lower case “a” and all other characters haven't changed since ASCII code was invented, nor have they changed for most of the average computer’s primitive instruction sets.
We always expect that a known cause has a known effect. If causality fails at this level, there’s no reason to trust computers to do anything consistently. There have been disastrous computer failures to match the physical failures I mentioned before. There was the Therac-25 software bug in a radiation treatment device that actually killed people back in the ‘80s and the more recent software failures of European Ariane rocket in the late ‘90s that destroyed the rocket just 37 seconds after launch. But, when the cause of the problems were found, it was a mistake in the code, not a failure of cause-effect that created the problems — more human error than violation of physical laws.
In the early days of computers, back in the ‘40s and ‘50s, it was not uncommon to run a problem through a computer several times, and get several different answers. If you got the same answer twice, that increased confidence. Modern computers have solved those engineering problems and are extremely consistent and, typically, give the same answer every time you run the program. However, even today, there can be bugs.
You may recall the issue with the Intel Pentium processor’s floating-point-divide error that caused all the concern and embarrassment to Intel back in 1994. That embarrassment shows how society has built up an expectation that computers are accurate, they don’t fail in such a basic way. Of course, people know there are bugs, but they really expect super accuracy from the computers regardless.
Most of us don’t even look at our bank statements, and we assume the calculators don’t make math errors — and they typically don’t!
Computers and Information
Ultimately, information is central to software because humans designed it that way. Information in software has two roles: actions (instructions) and data (meaning). Niklaus Wirth, the creator of the programming language Pascal, wrote a book called “Algorithms plus Data Structures Equals Programs.” That is the great “binary” in computer science: actions (algorithms) and data.
Each computer instruction or “op code” in an instruction set does one thing only. For example, if we want to copy the contents from address A to address B, we expect to find the address content to be the same after the instruction is executed. That is, the data in address A has been perfectly transferred to address B. This is information in its most primitive form. There is nothing ambiguous, emotional, lyrical, romantic, or uncertain about what instruction sets do. they manipulate zeros and ones. An instruction set for computers is information as action and the instructions implement the algorithms.
But information’s other role — as data — is where software escapes our grasp. As data or symbol, information must be meaningful to be useful to humans. Shannon’s 1948 paper was explicit about this: his theory describes the changed state of bits communicated between two points, where the bits are meaningless and irrelevant to the engineering problem under consideration. For humans, data or symbols that lack meaning simply aren’t information.
If there are any laws of meaning, all the historians, philosophers, logicians, mathematicians, philologists, linguists, physicists, chemists, biologist, economist, and story tellers of the world have yet to reveal them. Many have tried, from Aristotle to Plato and Paul of Tarsus (yes the biblical Paul), from Renee Descartes to Confucius to Thomas Aquinas to Avicenna, from Zeno to Epicurus to John Locke. The modern Alfred North Whitehead and Bertrand Russell, although they made great strides, did not codify knowledge. You can learn more about knowledge from Shakespeare than Kant and from George Bernard Shaw and Neil Simon (or Lennon and McCartney) than from Edmund Gettier. Not that these great thinkers and communicators didn’t have ideas worth learning, but it is not wrapped up in a concise set of formulas and relationships like math and physics. So how can it be engineered?
At the physics and mathematical level, software engineering is constrained by natural laws. Humans designed computers to work with absolute fixed states, “on” or “off,” zero or one, as Turing machines demand. These states are always certain and deterministic.
Yet humans also imposed meaning on these on-off bits. But imposing ambiguous, arbitrary, and paradoxical meaning onto something that’s inherently certain and deterministic doesn’t make the latter the former. Our freedom to impose meaning doesn’t compel the underlying physics and mathematics to accept our impositions, nor does our freedom to form nonsense phrases and symbols free us from natural laws.
Perhaps this is the sentient / non-sentient divide. Artificial intelligence substitutes probability for determinism, yet still misses the mark of true knowledge. It is said that we live in the “information age.” Certainly we live like the Venetians, surrounded by an ocean of information flowing right by our front door. But the pure volume of the sea of information makes knowledge difficult to distill from the information, and computers have yet to solve that problem with an appropriate algorithm.
From my perspective after spending a life studying these topics, subjects, and disciplines, software engineering will never attain the status of scientific method required of engineering for two reasons.
First, the meaning of the information that we impose on our systems is arbitrary — the “I say potato, you say potahto” problem. Second, as Kurt Gödel so aptly identified, the irreconcilables of software engineering can’t be resolved within the discipline itself. If we want to find a solution to this paradox, we must look outside the software engineering box.
Conclusion
So that leaves me with a quandary. I’ve done engineering, math, and physics. I’ve studied the science of computers and algorithms. Where do I go for wisdom? There is an answer, non-scientific, yet an answer that is true. This then is the quest, the quest for wisdom, the quest for truth. It isn’t engineering at all, and Dorothy was right, “we’re not in Kansas any more.” That other eight year old didn’t end up driving garbage trucks. He sought knowledge and wisdom that is eternal. God bless you Tom.
No comments:
Post a Comment