Software, Science, and Math

The Wayback Machine - https://web.archive.org/web/20050615235108/http://www.geocities.com:80/tablizer/science.htm "Computer Science" is Not Science and "Software Engineering" is Not Engineering Updated 3/8/2005 I have been in a lot of "software engineering" debates, perhaps too many. It is frustrating that there are heavy opinions about the "right way" to make software, but no easy way to objectively compare them to settle long-standing arguments. I have been pondering and studying why this is the case, and think I am finally able to articulate an answer. If the software discipline is "science", then the scientific process should be available to settle arguments. But it seems to fail. Some suggest that instead it is "engineering", not "science". But engineering is nothing more than applied science. For example, in engineering, bridge designs are tested against reality in the longer run. Even in the short run, bridge models can be tested in environments that simulate reality. Simulations are a short-cut to reality, but still bound to reality if we want them to be useful. If a bridge eventually fails, and the failure is not a construction or materials flaw, then what is left is the engineering of the bridge to blame. An engineer's model must be tightly bound to the laws of physics and chemistry. The engineer is married to the laws whether he/she wants to be or not. But we don't have this in software designs for the most part. We have the requirements, such as what the input and output looks and the run-time constraints which dictate the maximum time a given operation is allowed to take. But there is much in-between these that is elusive to objective metrics. Most of the techniques and paradigms under common debate can usually deliver the requirements. This is because they are "Turing equivalent", which basically means they are capable of implementing any clearly-specified algorithm, given enough time and resources. The bottom line is that delivering the required results is not a distinguishing factor; they can all do it. There are some specialties, such as Artificial Intelligence, where the answer is not necessarily "fixed". The "answer" is judged more or less on a continuous scale. In these situations different algorithms are compared and the results are ranked.

For example, a metric similar to a lab-rat maze test for intelligence testing can be performed to evaluate performance. However, just because a given algorithm is known to be better, this does not tell us if it is the "right" or only possible algorithm. It might be the "best known" at a given point in time, but not much can be concluded beyond that. As expounded upon later, we don't know what we don't know. Some options under debate may run slower, but that is usually not the key point in debates. Somebody will argue that higher developer productivity makes up for the slower speed (or need for bigger machines) or that in a few decades chips will be fast enough such that it does not matter. Developer productivity is possibly another metric that is measurable, but is still elusive because there too many variables. I will return to productivity later because it is indeed an important issue. So, if physical engineering is really science ("applied science" to be more exact), but software design does not follow the same pattern, then what is software design? Perhaps it is math. Math is not inherently bound to the physical world. Some do contentiously argue that it is bound because it may not necessarily be valid in hypothetical or real alternative universe(s) that have rules stranger than we can envision, but for practical purposes we can generally consider it independent of the known laws of physics, nature, biology, etc. The most useful thing about math is that it can create nearly boundless models. These models may reflect the known (or expected) laws of nature, or laws that the mathematician makes up out of the blue. Math has the magical property of being able to create alternative universes with alternative realities. The only rule is that these models must have an internal consistency: they can't contradict their own rules. (Well, maybe they can, but they are generally much less useful if they do, like a program that always crashes.) Software is a lot like math, and perhaps is math according to some definitions. The fact that we can use software to create alternative realities is manifested in the gaming world. Games provide entertainment by creating virtual realities to reflect actual reality to varying degrees but bend reality in hopefully interesting ways. A popular example is The Sims, which is a game that simulates social interaction in society, not just physical movements found in typical "action" games. Most games tend to borrow aspects or laws of the physical world.

This is because game purchasers are more likely to buy something that they can relate to in one way or another. But making worlds that have little or nothing to do with the physical world are also possible. Worlds can be created where anti-gravity is plentiful, for example. Things would fall up. Or, time could run backward, sideways, bump into other time- lines, etc. (I know, I watch too much Star Trek, I admit.) One could also play with social and economic rules that we normally assume are fixed or static. Researchers have even evolved simple artificial life-forms using "genetic algorithms" in order to experiment with the Darwinian theory of natural selection. It involves artificial food, artificial energy, artificial sexual and asexual reproduction, etc. The only limitation is the imagination of the creator of the virtual world (and perhaps the pesky limitations of computer resources). As long as they can define the rules clearly, they can make a universe that follows those rules. They build the rules into software, press the "run" button, and then sit back and watch. If you have an urge to play God, software is currently the best game in town. Unlike your in-laws or baby brother, the computer won't complain about your attempt at domination. This nearly infinite flexibility of software, I have concluded, is why objective software design evaluation is nearly impossible: there is no objective reality inside software. This is the secret cause of all the debate headaches. We might as well be a bunch of loonies in the mental hospital arguing over which one of us is the real or best Napoleon. The difference is that in cyberspace we can all be Napoleon. Some have suggested that the reasons for lack of objective metrics are because we don't know enough yet; that we just haven't learned how or what to measure. Instead, the problem is that we can manufacture what we "know". Today you are Santa Clause, tomorrow Cleopatra. This can be both in a literal sense, such as a role-playing game, or a figurative sense, such as software organization principles. In software design there are many possible different design paths to provide the correct answer. But if there are many solutions to the same problem, which one is "better"? One possible answer is, "maybe it does not matter". As long as the software takes the input and produces the right output, then why care how it works?

If a black box works, then why worry about how the innards work? One of the reason the innards do matter is because different programmers have to maintain (fix or change) software code made by others. Using our God analogy, if God goes on vacation or retires, then his replacement needs to know how the world works in order to keep it running. Real gods may have infinite comprehension skills such that they can quickly figure it all out, but humans have built-in comprehension limitations. It costs us time and money to figure out how something works. Thus, it is nice to have conventions that make it easier for person A to understand the work of person B. But the next logical follow-up question is whether some conventions are inherently "better" than others. Conventions alone may help with communication, but are all conventions created equal? Since these conventions are related to communication, we must know more about the communication process in humans to answer the "better" question. But this seems inherently tied to psychology. If our answers depend on knowledge of human psychology, then we cannot yet claim we have objective tools to compare conventions because psychology by definition is about subjectivity. Plus, psychology is still an immature field of study compared to say physics. Further, every brain is different. A truth or pattern found in brain A may not necessarily also be in brain B. Maybe when the human brain is finally fully decoded and we understand how it works in detail, then Computer "Science" will graduate into a hard science. Further, there has not been sufficient cooperation between psychology researchers and software researchers. Most psychology research is geared toward curing or reducing "big" problems, such as extreme depression, schizophrenia, etc. Barring finding a buried treasure, that is where most of the research effort understandably goes. "Industrial psychology" will only receive pocket change in comparison, but it will probably take much more than that to answer the big questions. Ironically, if we knew enough about brains to answer such questions, we could probably use such knowledge to build electronic versions and make the need for human programming mostly obsolete. It is true that the first models will probably fill a room, but based on past patterns it wouldn't take long to shrink the technology and mass manufacture it. Now we come back to programmer productivity, which is the second reason to be concerned with the innards of our black box.

If virtual words can be built, changed, and debugged faster, then companies can save money and hopefully make the economy more efficient. Thus, focusing on productivity techniques is clearly a useful endeavor. The problem is that there does not seem to be many studies done in this area. Some claim that the size of code corresponds to productivity such that a program with 2,000 lines or tokens is easier to write and maintain than one that is 10,000 lines or tokens. But there are heavy debates on both sides about whether size alone translates into productivity. For example, Perl code can often be written to be small in size, but many find it notoriously difficult to read. It also depends on the problem domain. Some of the best examples of small code I've ever seen are from "collection oriented" languages, such as APL's derivatives. However, they were toy problems that are hard to extrapolate into many real-world situations. There are just too few good direct studies on productivity. For example, researchers could lock a bunch of programmers in different rooms with the same specification. Each room would use a different language or paradigm and we then see who finishes first. However, there are complications to this. Code that runs is not necessarily code that makes for easy maintenance, and many languages and paradigms are allegedly geared to optimize maintenance, not initial product delivery. We can't keep the test subjects sequestered for years on end just to test long-term maintainability. No viable company or government is going to allow this with real projects. My personal observation in combination with bits of Edward Yourdon's studies suggest that the paradigm or language that a given developer is most comfortable with is the one that makes them the most productive. This would mean that to get optimum productivity, hire a bunch of like-minded developers who are fanatics of a given language or tool. The bottom line is that empirical science is sorely lacking in our field. If that's the case, then what is in all those volumes of "computer science" books that are available? They gotta be writing about something in all those since they are not blank pages. There are various techniques, idioms, tools, etc. commonly used in software, and most of the academic writings seem to be about these. Examples include: Boolean Algebra Object Oriented Programming Data Structures (lists, sets, queues, stacks, etc.) Algorithms (sorting, searching, traversing, etc.)