What we think of today as being “computers” started out in the minds of mathematicians as purely abstract devices–thoughts about how to solve math problems using machines instead of the mind.
These mathematicians are the people we would consider the modern founders of “computer science.” Computer Science is actually the mathematical study of information processing. It is not, as some people believe it to be, the study of computer programming. In fact, there is no science of computer programming. To understand how that could possibly be true, and what I mean, you have to know the history of programming.
The earliest computers were built under the supervision of computer scientists by highly skilled electronic engineers. They were run by highly-trained operators in tightly-controlled environments. They were all custom-built by the organizations that needed them (mostly governments, to aim missiles and crack codes), and there were only one or two copies of any given model.
Then, along comes UNIVAC and the whole notion of “commercial” computers. Now, there’s only so many advanced theoretical mathematicians in the world. If you start shipping out computers to everybody, you can’t ship a mathematician along with each one. So although some organizations, such as the United States Census Bureau, almost certainly had some highly-trained operators for their machinery, other organizations undoubtedly got their machine and said, “Okay, Bill from Accounting, this is yours! Read the manual and have at it!” And there went Bill, diving into this complex machine and doing his best to make it work.
Bill there is our first “working programmer.” He might have studied math in school, but he almost certainly didn’t study the sort of advanced theory needed to conceive and design the machine itself. But he can read the manual and understand it, and by trial and error, make the machine do what he wants.
Of course, the more commercial computers you ship, the more Bills you have and the fewer highly-trained operators you have. And if there’s one thing that Bill has, it’s job pressure. He has demands from management to “Get that task done now!” and “We don’t care how it’s done, just do it!” He figures out how to make the thing work according to its manual, and it works, even if it crashes every two hours.
Eventually Bill gets a whole team of programmers to work with him. He has to figure out how to design a system and split up the tasks between different people. Instead of being studied and mapped out like a standard science, the whole art of practical programming grows organically, more like college students teaching themselves to cook than like NASA engineers building a space shuttle.
So there’s this hodge-podge system for software development, and it’s all very complex and hard to manage, but everybody gets along somehow. Then along comes The Mythical Man Month, a book by a guy who actually looked at the process of software development and pointed out some things about it–most famously that adding more programmers to a project doesn’t necessarily make it faster. He didn’t come up with a whole science, but he did make some good observations about programming and managing software development.
Of course, then came a flurry of software development methods: the Rational Unified Process, the Capability Maturity Model, Agile Software Development, and others. None of these claim to be a science, just a way of managing the complexity of software development.
And that, basically, brings us up to where we are today: lots of “methods,” but no real science.
A science is composed of observations, experiments, and laws. Although we have hundreds of books of observations about practical programming, and “the world is our laboratory”, all of that has resulted in very few laws, which are the most important part of a science. That is, instead of coming up with methods to work around complexity, there ought to be some fundamental rules to follow that would lead to simplicity–ways to avoid complexity entirely and explain why what “works” in software development does work.
In reality, there are two missing sciences here. The first one is being worked on actively, and includes the various methods I mentioned above. That’s the science of managing software development. The fact that conflicting, equally-valid “opinions” seem to exist within the field indicates that the fundamental laws of software management have not been worked out. However, there is at least attention being given to the problem.
The other science, though, gets very little attention in the practical world of programming: the science of writing software. Very few people are taught that there is a science to writing software, in school. Instead, they are just shown “This is how it works in this programming language, now go write some software!”
The science I’m talking about is not Computer Science. That’s a mathematical study. I’m talking about a science for the “working programmer”–something that gives fundamental laws and rules to follow when writing a program in any language. One that’s as reliable as physics or chemistry in telling you how to create an application.
Some people might say that such a science is not possible, that software development is too variable to ever be described by simple, fundamental laws. Some people also once said that understanding the physical universe was impossible because “it is the creation of God and God is unknowable.” So unless you’re telling me computers are unknowable, I think that making such a science would be entirely possible.
Actually, I’ve started to collect some basic hypotheses for such a science, and I’m writing a book about it. I might post some of them here, but actually, all of what I’ve written in the blog so far actually comes from those hypotheses. That is, I haven’t really posted any of my hypothetical “laws” yet, but I have been posting data that I’ve derived from them.
Anyhow, I think that the primary source of complexity in software is actually the fact that this science is lacking. If programmers actually had a science for simplicity in software, there wouldn’t be nearly so much complexity, and we wouldn’t need crazy processes to manage that complexity.
Whenever there’s a problem with something, my instinct is to go philosophically above the level of the problem and look at it from there. If there’s some “unsolvable” effect happening to something, there must be some unknown cause on a higher level. So there you go–if the problem is complexity, then maybe it’s because there was no science of simplicity in the first place.
-Max
Could you really ever consider methodology a science? It’s like how do you build a building? Sure, there is a well defined method out there that accurately defines a good way at building large, structuraly sound buildings that has come about using extensive imperical research on the subject. But there’s no reason to believe that at some point someone won’t come along and show another, more efficient method.
The reason is because it’s an art, like drawing a good picture, or writing a good song. No matter what attempts you put on simplifying what goes in to a good piece of art, there is always a better, newer way.
Yeah, I never would consider a methodology a science.
But in your analogy of buildings, there is the science of physics. That is, we know fundamentally what will stay up and what won’t because we can look at gravity and all that. The methodology (or “technology”) is “21st century skyscraper architecture” but the science is physics. That’s the theoretical base that describes laws.
There’s always an art to the application of a science, but I think there still could be a science behind any art. That doesn’t make it any less the creation of the individual, though. 🙂
-Max
So carrying the analogy back to software, wouldn’t “computer science” be the science that underlays the methodology of programming? Doesn’t computer science discover/document/define the fundamental “laws of nature” of the environments in which programs execute?
I see the sciences as determining the constraints of an environment. What you do within those constraints isn’t science, that’s engineering (or art, or mucking around in the basement). Maybe what you’re looking for is a version of software engineering that isn’t so tightly bound to specific technologies?
Computer science primarily defines mathematical models of systems that could exist or systems that do exist. A mathematics is not necessarily a science, just as a science does not necessarily have a mathematics. That is, just because we can model the patterns of something (and mathematics is fundamentally the study of patterns) something doesn’t mean that we understand the laws behind it.
Computer science would be the science of algorithms, and the science of mathematically modeling the machines that those algorithms can run on. It is also sometimes described as the science of information processing. It doesn’t necessarily give us processes for putting together systems, or tell us what designs would be better for us as programmers. It’s mostly focused on the machine, not on the people using or instructing the machine.
You’re right that a “version of software engineering” would be much closer to what I’m talking about. 🙂 I went over that more in the blog after this one.
-Max
very good
Hi Max,
I’ve been thinking about this one for a while. I think your right about the missing science, but as in your example of physics to skyscrapers, I figure the problem is ‘information’ to programming. Something like:
http://theprogrammersparadox.blogspot.com/2008/03/science-of-information.html
Paul.
Well, supposedly Computer Science is the science of information. It just has a bad name. That whole aspect of things (“What is Computer Science, really?”) is somewhat confusing, though.
-Max
Also, you might be interested in studying General Semantics. Not its therapy aspects, but just its theoretical aspects.
I suppose that the nature of the organization of information is so natural to me that I had never thought about it.
-Max
Hi Max,
Yes, General Semantics looks interesting, I’ve just glanced at the wikipedia page, but it was enough to suggest that I might want to dig around there a bit.
In watching people build systems over the years, I’ve come to realize how often they are just guessing about the structure of data. They’ll convince themselves of a specific structure, but if another better one arrives, they’ll convince themselves of that one too. If we know how the data is actually structured, and we know what subset of the data we want, and the users know how they want to view it, then the rest is just connecting the dots.
Paul.
Yeah, that’s interesting. I think you actually could indeed have a science, actually a subset of what I talk about in the blogs after this (only a subset because it would almost certainly governed by the laws of design). I mean, my first instinct was to say, “Well, that’s something you have to figure out for each project,” but that’s the sort of typical “blah blah that’s impossible” answer that I myself always dislike. 🙂
In order to organize any information you need a guiding principle. That is, information can only be structured when there is some other fact to evaluate it against. For example, “I am green” and “I am five feet tall” could be in the same category, different categories, or related categories, depending on what guiding principle we choose.
The danger here is slipping into mathematics without first a focus on practicality. Because “information” is an abstract subject, it’s too easy to treat it abstractly and not come up with something that would actually be practically applicable.
-Mxa
[…] There is no science of software design in existence and broadly-known, currently, which opens to door to anybody coming along and dropping any authoritarian pronouncement that they like into the field, with an abnormally large number of developers only too eager to slurp up the statements on faith to fill the vacuum of data that exists in software design. […]