Software, Science, and Math

35 captures<br>07 Apr 2005 - 21 Feb 2025

May<br>JUN<br>Jul

15

2004<br>2005<br>2006

success

fail

About this capture

COLLECTED BY

Organization: Alexa Crawls

Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.

Collection: alexa_ed

this data is currently not publicly accessible.

TIMESTAMPS

The Wayback Machine - https://web.archive.org/web/20050615235108/http://www.geocities.com:80/tablizer/science.htm

"Computer Science" is Not Science and<br>"Software Engineering" is Not Engineering

Updated 3/8/2005

I have been in a lot of "software engineering" debates,<br>perhaps too many. It is frustrating that there are heavy<br>opinions about the "right way" to make software, but no<br>easy way to objectively compare them to settle<br>long-standing arguments. I have been pondering and studying<br>why this is the case, and think I am finally able to<br>articulate an answer.

If the software discipline is "science", then the scientific<br>process should be available to settle arguments. But it<br>seems to fail. Some suggest that instead it is<br>"engineering", not "science". But engineering is nothing<br>more than applied science. For example, in engineering,<br>bridge designs are tested against reality in the longer run.<br>Even in the short run, bridge models can be tested in<br>environments that simulate reality. Simulations are a<br>short-cut to reality, but still bound to reality if we want<br>them to be useful. If a bridge eventually fails, and the<br>failure is not a construction or materials flaw, then what<br>is left is the engineering of the bridge to blame. An<br>engineer's model must be tightly bound to the laws of<br>physics and chemistry . The engineer is married to<br>the laws whether he/she wants to be or not.

But we don't have this in software designs for the most<br>part. We have the requirements, such as what the input<br>and output looks and the run-time constraints which<br>dictate the maximum time a given operation is allowed to<br>take. But there is much in-between these that is elusive to<br>objective metrics. Most of the techniques and paradigms<br>under common debate can usually deliver the<br>requirements. This is because they are "Turing<br>equivalent", which basically means they are capable of<br>implementing any clearly-specified algorithm, given<br>enough time and resources. The bottom line is that<br>delivering the required results is not a distinguishing<br>factor; they can all do it.

There are some specialties, such as Artificial Intelligence,<br>where the answer is not necessarily "fixed". The "answer" is<br>judged more or less on a continuous scale. In these situations different<br>algorithms are compared and the results are ranked.<br>For example, a metric similar to a lab-rat maze test for intelligence testing<br>can be performed to evaluate performance.<br>However, just because a given algorithm is known to be better,<br>this does not tell us if it is the "right" or only possible<br>algorithm. It might be the "best known" at a given point in time,<br>but not much can be concluded beyond that. As expounded upon later,<br>we don't know what we don't know.

Some options under debate may run slower, but that is<br>usually not the key point in debates. Somebody will<br>argue that higher developer productivity makes up for the<br>slower speed (or need for bigger machines) or that in a<br>few decades chips will be fast enough such that it does<br>not matter. Developer productivity is possibly another<br>metric that is measurable, but is still elusive because<br>there too many variables. I will return to productivity<br>later because it is indeed an important issue.

So, if physical engineering is really science ("applied<br>science" to be more exact), but software design does not<br>follow the same pattern, then what is software<br>design? Perhaps it is math. Math is not inherently bound<br>to the physical world. Some do contentiously argue that it is<br>bound because it may not necessarily be valid in hypothetical<br>or real<br>alternative universe(s) that have rules stranger than we<br>can envision, but for practical purposes we can<br>generally consider it independent of the known laws of<br>physics, nature, biology, etc.

The most useful thing about math is that it can create<br>nearly boundless models. These models may reflect the<br>known (or expected) laws of nature, or laws that the<br>mathematician makes up out of the blue. Math has the<br>magical property of being able to create alternative<br>universes with alternative realities. The only rule is<br>that these models must have an internal consistency: they<br>can't contradict their own rules. (Well, maybe they can,<br>but they are generally much less useful if they do,<br>like a program that always crashes.)

Software is a lot like math , and perhaps is math<br>according to some definitions. The fact that we can use<br>software to create alternative realities is manifested in the<br>gaming world. Games provide entertainment by creating<br>virtual realities to reflect actual reality to...