

"Computer Science" is Not Science and "Software Engineering" is Not Engineering - currywurst
http://www.geocities.com/tablizer/science.htm

======
espeed
"Underlying our approach to this subject is our conviction that 'computer
science' is not a science and that its significance has little to do with
computers. The computer revolution is a revolution in the way we think and in
the way we express what we think. The essence of this change is the emergence
of what might best be called _procedural epistemology_ ­ the study of the
structure of knowledge from an imperative point of view, as opposed to the
more declarative point of view taken by classical mathematical subjects.
Mathematics provides a framework for dealing precisely with notions of 'what
is.' Computation provides a framework for dealing precisely with notions of
'how to.'"

\-- Preface to the First Edition of _Structure and Interpretation of Computer
Programs_ (<http://mitpress.mit.edu/sicp/front/node3.html>)

~~~
ten_fingers
> Mathematics provides a framework for dealing precisely with notions of 'what
> is.' Computation provides a framework for dealing precisely with notions of
> 'how to.'"

But some parts of math deal "with notions of 'how to'" and there commonly do
so more "precisely" than computer science. There are such parts in
optimization, control theory, statistics, and numerical analysis.

E.g., numerical analysis says how to (1) solve systems of linear equations
numerically exactly using just single precision arithmetic, (2) solve systems
of linear equations with accuracy guaranteed by error bounds from condition
number, (3) solve systems of large, sparse linear equations where the matrix
is large, positive definite, and diagonally dominate, (4) how to solve
ordinary differential equation initial value problems, e.g., for space flight
trajectories, and (5) how to solve partial differential equations of heat
flow, fluid flow, and electromagnetic fields, and (6) how to do discrete
Fourier transforms of positive integer n points in time proportional to n
log(n) instead of n^2; statistics says how (1) to get minimum sufficient
statistics in the Gaussian case, (2) how to design a most powerful statistical
hypothesis test, (3) how to pick a survey sample size that will give desired
accuracy, (4) how to get minimum variance, unbiased estimators in multivariate
statistics, and (5) at a Web site with users arriving at a rate of 10 a
second, how to find the probability of a minute with arrival rate of over 20 a
second; control theory can show (1) how to execute best possible decision
making over time under uncertainty, (2) how a rocket can reach orbit for
minimum fuel, (3) how an airplane can climb to a given altitude in least time;
and optimization can show (1) how to find least cost flows on large networks
while avoiding cycling in the network simplex algorithm, (2) how to assign
interceptors to targets in the best possible way in guaranteed execution time,
and (3) how to assign signals to satellite channels to minimize the worst case
of signal interference.

~~~
kilburn
Do you have a reference for "(2) how to assign interceptors to targets in the
best possible way in guaranteed execution time"? I would love to read that
paper!

~~~
ten_fingers
The specific problem is a special case of the 'assignment' problem. First cut,
it looks like 0-1 integer linear programming and, thus, maybe in NP-complete.

Looked again, the problem is least cost network flows. That is a linear
programming problem. In that problem, if the arc capacities are integers, and
in this practical problem they are, then the simplex algorithm can easily
start with a basic, feasible, integer solution, and the simplex iterations
will automatically maintain an integer solution and, then, find an optimal
integer solution which provides the optimal assignments.

When we apply the simplex algorithm to least cost network flows, we get to
take advantage of the fact that the problem is not fully general linear
programming, and the advantage we can take is huge. E.g., the arcs of a basic,
feasible solution form just a spanning tree in the network; the 'entering
variable' in the simplex algorithm just adds an arc to the spanning tree and,
thus, yields a circuit; we run flow around the circuit in the direction that
makes money until the flow on some arc is zero and that arc determines the
'leaving variable'. Using the 'strongly feasible' basis ideas of W.
Cunningham, long at Waterloo, we can avoid cycling.

But, the simplex algorithm for least cost network flows, as far as I know, is
not guaranteed, worst case polynomial.

However, read:

Dimitri P. Bertsekas, 'Linear Network Optimization: Algorithms and Codes',
ISBN 0-262-02334-2, MIT Press, Cambridge, MA, 1991.

and in there, or elsewhere in Bertsekas's work, is an algorithm for least cost
network flows and that is worst case polynomial.

Done.

And I covered nothing classified!

And for this thread, we have a "how to" with high precision from some applied
math.

------
polshaw
As someone with an engineering degree, it does irk me to constantly hear
programmers referred to around these quarters as 'engineers', it's extremely
introspective, and IMO a little disrespectful. Similarly to the 'are you
technical?' thing, why is there such an aversion to the term programmer or
software developer?

I have no problem with the term 'software engineers', as i do seem _some_
parallels, and it is clear what you are talking about, but please leave the
straight up 'engineering' term to those dealing with the physical world.

 _E:_ most replies and downvoters seem to have missed that I have no problem
with the term where it is unambiguous. You wouldn't call a software architect
simply 'an architect' (would you?).

~~~
barik
"As someone with an engineering degree, it does irk me to constantly hear
programmers referred to around these quarters as 'engineers', it's extremely
introspective, and IMO a little disrespectful."

I'm not certain it has anything to do with the physical world; after all
Industrial Engineering is considered a valid disciplined that is entitled to
an Engineering license, and many of the IE's I know might be better
characterized as mathematicians.

Still, I tend to agree with your assessment of the term Engineer, although
it's largely because unlike other Engineering fields, Software Engineers in
the US seem to be happy to hold the title without having to meet any of the
legal requirements [1]. A PE license, while not insurmountable, is not exactly
the easiest title to acquire. Efforts have been proposed to make Software
Engineering part of this licensing process, but it seems to have a lot of push
back. Perhaps the solution is to have legal weight (perhaps like 'Lawyer' or
'MD') behind the title, as countries like Canada have (the US has this to some
extent, but it's not nearly as strong).

[1] <http://www.ncees.org/Exams/PE_exam.php>

~~~
Niten
> Perhaps the solution is to have legal weight (perhaps like 'Lawyer' or 'MD')
> behind the title, as countries like Canada have (the US has this to some
> extent, but it's not nearly as strong).

But here you're taking it for granted that professional licensure of software
engineering is actually desirable, which is not at all agreed upon. Among the
organizations against the notion are the ACM.

~~~
AYBABTME
I think one of the problems is that professional licensure of software
engineering would require the codification and legalization of a set of
knowledge and standard agreed upon. This set of knowledge would be used as a
metric of what is expected from an 'reasonable' engineer, thus making any
professional engineer liable toward society (and more specifically toward
courts) to meet those standards.

The problem in this is that nobody agrees on this set of standard/knowledge (a
Body Of Knowledge). For instance, if the document and the experts required to
testify in court define that "a reasonable engineer has to use a waterfall
methodology", then you could be liable for using an agile methodology (that's
just an example). The domain being so young, there is not yet an agreed upon
profile of what a 'reasonable software engineer' might be. The SWEBOK[1]
attempt to define such a profile was initially supported by both IEEE and ACM,
but - if I remember well - the ACM dropped their support in face of these
concerns.

I think both organizations support the legalization of the "Software
Engineering" field (and perhaps title), but also recognize that the field is
not yet mature enough to be properly defined and regulated.

Disclaimer: I do not have sources for my claims on IEEE and ACM's positions on
the matter; I merely read about it a few months ago. However, you can find
interesting conversations on the subject by googling 'SWEBOK'.

[1]<http://www.computer.org/portal/web/swebok>

------
padobson
So, building a bridge is an engineering endeavor.

Does this mean that drawing blueprints for the bridge is not engineering? What
about working a crane? Laying brick? Sealing pavement? Sweeping the bridge?

Could you say that an AWS datacenter is not a feat of engineering? Certainly
writing the software that powers it is as important as any other discipline,
and every piece of its execution has definable metrics to measure performance.

I've known janitors who sell accounts and measure their foot steps to find the
fastest cleaning path. If you sell janitorial services for $2000 a month and
it only takes you 2 hours a night to do a job, then you'll make as much money
as some engineers. Not that salary is the measure of an engineer, but using
math and science to maximize favorable outcomes should be.

Or maybe thats just the measure of a hacker.

~~~
thomseddon
Whilst I don't necessarily disagree with the point you are working towards, I
don't follow your pedantic breakdowns of various endeavors.

"Drawing" the blueprints would be done by a draftsman not necessarily an
engineer, working a crane is a skilled job done by crane operators (again not
necessarily engineers), and brick laying/pavement sealing/bridge sweeping is
again not necessarily done by an engineer. In building a bridge, the
"engineering" is done by the civil engineer who designs the bridge, chooses
and calculates its construction: "applying scientific knowledge, mathematics
and ingenuity to develop solutions for technical problems."

Similarly, a datacenter may be considered a feat of engineering, but the
construction (read: design) of the datacentre is done by civil/structural
engineers and is separate from this argument (although this may not have been
what you were getting at, my interpretation was that you were initially
including the building in your point).

I would argue that if a janitor was to optimise his/her route by counting
steps, this is not a technical problem and so doesn't make him an engineer.

~~~
erichocean
_I would argue that if a janitor was to optimise his/her route by counting
steps, this is not a technical problem and so doesn't make him an engineer._

Doing so is called "industrial engineering".

------
foldingstock
"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 like 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.
"

I pretty much stopped reading here. Elusive to objective metrics? I agree that
you can't measure a program like you would a bridge, using physical laws such
as physics and chemistry, but you very well can measure many aspects of it
such as: efficiency, size, required resources, relative ease of use, etc. Just
because it is not a physical thing doesn't mean we can't use a "scientific
method" approach, we just need to be open to using metrics that exist in the
digital realm.

~~~
polshaw
All of your points could be applied to, say, a manager in a business, but
nobody would call them a employee engineer or business scientist.

~~~
vonmoltke
The world does have, rightly or wrongly, "process engineers" who use metrics
to modify and optimize processes, physical or business. Just look at how
widely the attempts to employ Six Sigma have been.

That said, being able to measure something isn't sufficient; one also needs
the control to modify the thing being measured in a way that has deterministic
effects on the metrics. GP's metrics have that feedback loop with respect to
software, which pushes it towards engineering. Process engineers have that
feedback loop, even on business processes. Your manager does not; most of
their actions do not create deterministic results.

------
betawolf33
The contention that Computer Science is not a science because on opening a CS
textbook you get confronted with a number of mathematical concepts seems a
fairly ridiculous one. The same argument could be made to say that Physics is
not a science, after all.

The problem is that there's a conflation in most people's minds of the terms
'computer science' and 'programming'. Computer Science courses teach you how
to program, so this is understandable. But the research that goes on in
Computer Science departments is not all about 'how to program'. Hypotheses are
generated and tested for specific end-goals.

Sure, CS is highly mathematical in its execution, and the introspective areas
of research are thus mathematical. Some of the research in the Algorithms
areas is probably best published in mathematical journals. But that's not the
whole science. What about measurements of routing efficiency in Networking?
What about HCI? What about Ubicomp? What about NLP, or even AI in general?
Even if they are using mathematical principles in forming their systems for
experimentation, they're still doing science. Hell, all sciences rely on maths
somewhere.

~~~
SeanLuke
I think that this is basically saying "Computer Science is science because it
_uses_ science." But Electrical Engineering uses just as much scientific
method in its research papers as CS does. Does this make EE a scientific
field?

To my mind, every engineering field has _researchers_ who use the scientific
method every day to produce stuff for the engineers to use. The field is not
defined by those researchers -- it's defined by the users (engineers). EE
researchers often publish stuff based on the scientific method, or by proof,
but the end product is meant to be used by engineers. CS researchers often
publish stuff based on the scientific method, or by proof, but the end product
is meant to be used by ... well, we call the "programmers". But they're
engineers of software.

~~~
betawolf33
Interesting perspective. My thought is that CS is what we call what those
researchers do to differentiate it from what the users do.

Creating a new tool through the scientific method would be the science,
whereas implementing a system or product would be the 'software engineering' -
the application of the science. I don't have a good basket term for both
research and application, but I'd probably go for something like 'Computing'.

This could be applied to any engineering field as well, it's just a matter of
naming practices. I'd be happy to admit that 'electrical engineering science'
existed (though the name is horrible) to refer to the research in electrical
engineering.

------
yanatan16
Quote from <http://wikipedia.org/wiki/engineer> "An engineer is a professional
practitioner of engineering, concerned with applying scientific knowledge,
mathematics and ingenuity to develop solutions for technical problems.
Engineers design materials, structures and systems while considering the
limitations imposed by practicality, safety and cost. The word engineer is
derived from the Latin roots ingeniare ("to contrive, devise") and ingenium
("cleverness")."

Software engineers definitely fall under this definition.

~~~
stephengillie
Etymology is one area where I know not to trust Wikipedia. I'm pretty sure an
"engine-er" maintains an "engine", in the act of "engineer-ing".

~~~
steverb
Would you trust dictionary.com? It agrees with Wikipedia.

Origin: 1350–1400; engine + -eer; replacing Middle English engin ( e ) our <
Anglo-French engineor Old French engigneor < Medieval Latin ingeniātor,
equivalent to ingeniā ( re ) to design, devise (verbal derivative of ingenium;
see engine) + Latin -tor -tor

<http://dictionary.reference.com/browse/engineer>

~~~
stephengillie
They both probably have the same incorrect source. I trust the OED.

------
robocaptain
I only clicked on this link because I saw the geocities.com. I was expecting
more BLINK tags and animated gifs :(

~~~
jabiko
I assumed all geocities.com sites have been deleted. How is this possible?

~~~
Auguste
Most are gone, but there seems to still be a few left up. No idea why.

------
Juniper
Reminds me of the statement by I think H. Abelson though it might have been
Sussman (from their SICP video lecture 1)that goes something like :

Computer Science is not a science and it's not about computers. Computer
science is only about computers in the same way that physics is about particle
accelerators.

That was the gist of it anyway

------
currywurst
My favourite quote from the article "... 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."

------
t_lark
The cross discipline Engineering workflow is: 1\. define metric of success 2\.
fiddle with system till metric is high enough. 3\. <optional> research
alternative 1.s and cheaper 2.s

Real software engineering, e.g. profiling optimization, is _definitely_ a
branch of engineering. Research into software architectures, is not.

Science is about disseminating the unknown. You do not do science in most
software jobs. You are doing science if you publish your results in scientific
journals. An example of real computer science is understanding how discrete
systems (such as DNA or CPUs) can turn into complex systems (such as life or A
life).

The author of this article has very little understanding of engineering or
science.

From a Engineer/Scientist

------
OlivierLi
In Québec Software Engineering is covered by the "Ordre des ingénieurs du
Québec".

Software engineers have to come from accredited engineering schools and take
the same exams as engineers from other fields.

They are also required to follow the same code of conduct.

~~~
jiggy2011
Does this mean that in order to charge money for any programming work at all
(even VBA) you have to have an accredited qualification, or can you do so but
not call yourself a software "engineer"?

~~~
OlivierLi
No it doesn't.

But the term Engineer is protected. You cannot legally call yourself an
Engineer if you don't have the degree.

~~~
snowwindwaves
I am not able to call myself an engineer unless I am a professional engineer,
until then I am an 'engineer in training' EIT. I think engineers should come
up with a better term for this 4 year period before they can become
professionals.

------
valdiorn
As a trained electrical engineer, working as a software "engineer", it is my
opinion that those quotation marks I just used are necessary.

I may be an engineer, but I'm not employed as one, even if it says so on my
business card.

~~~
benthumb
If this isn't engineering, I'd love to know what it is:
[http://techcrunch.com/2012/08/07/google-cars-300000-miles-
wi...](http://techcrunch.com/2012/08/07/google-cars-300000-miles-without-
accident/)

~~~
icegreentea
There are software engineers, and then there are software "engineers". Just
because because of their jobs involve programming does not make them all the
same. Just like how using CAD doesn't automatically make you an engineer.

There are definitely software endeavors and jobs that can be called works of
engineering. And then there are those in the grey areas, and then there are
those which are not.

------
fiatpandas
And, software architecture is not architecture.

;)

------
dromidas
This article truly deserves 'TL;DR'.

BUT, having lightly skimmed it, I get the general idea because "real"
engineers have been whining about the Software Engineer title since nearly the
first day I was at college like 11 years ago.

Oddly, perhaps, I haven't ever heard scientists complain that computer
scientists aren't scientists.

I can't speak so much about software engineers as that is not really what I
do, but as a computer scientist I can say without reservation that it is
indeed a science. Research and experimentation is a core part of a lot of what
computer scientists do. Solving problems that had no solutions until you came
along and invented them.

------
acheron
I don't know anyone who especially disagrees with this, but etymology is not a
consistent process. The term "software engineering" evolved for various
reasons; whether the discipline is actually covered under "engineering" is as
relevant as whether or not you're actually killing 1/10th of a population when
you "decimate".

Also, reminds me that my favorite description of my school
(<http://www.wpi.edu>) was that it specialized in "science, engineering, and
computer science", since of course CS is neither science nor engineering.

------
m0skit0
I almost do not agree with anything you say in this article, and I'm not
entering the details since most of them has already been commented here, but
just a point I feel like missing: software IS bound to laws of physics and
chemistry, because it runs on hardware, which is bound to such laws. Most of
the time, when engineering software (which is NOT the same as
coding/programming) you must take into account the hardware limitations, and
on last instance, test that software on some hardware and do optimizations
where needed.

------
stephengillie
"Computer" science is more like "computational" science - reducing everything
to numbers, using logic to make safe assumptions and find paradoxes, etc.
Humans can't compute as well as transistors so we use them for all of the
heavy thinking.

It's engineering in the same way that constructing a stainless steel table is
mechanical engineering (buy a sheet, cut it, put 8 bends in it, weld corners,
grind corners, polish corners with acid, weld legs on, grind leg welds, polish
leg welds)

------
philhippus
The software "engineering" argument is debatable, but computer science
certainly implies some classical scientific principles. Areas such as quantum
mechanics, relativity theory and thermodynamics are relevant in computer
studies. The subject of "Computer Science" is vast, at least equalling the
scope of more accepted scientific disciplines and probably stretching beyond.

------
nlz1
geocities.com sites are still there???

~~~
Wohlf
Exactly what I was thinking. It must be a graveyard of autoplaying music, hit
counters and flashing graphics.

------
SeanLuke
> Some suggest that instead it is "engineering", not "science". But
> engineering is nothing more than applied science.

This seems to be an entirely self-serving and arbitrary definition on which to
base his argument.

------
webcowboy
Also, Political Science.

------
Xyzodiac
Try telling that to my university, the majority of my non CS classes that are
required are suffixed with "for engineers".

------
amykhar
I never understand how such old content suddenly becomes popular around here.
This article is from 2005.

------
brandontreb
I can't trust anything this guys says since he's running on geocities.

------
mahmud
Ahhh yes, tablizer. He is still around I see.

------
vampirechicken
A chickpea is neither a chick nor a pea.

------
ten_fingers
For computing being 'engineering', that is an old sore point with me. I
believe that computing should be engineering but so far really misses some key
points.

Here, close to the article, is an example of some of what is missing:

In engineering for, say, a bridge, the design engineer can get quite
comprehensive data on the 'engineering properties' of the materials,
components, and processes he is intending to use. E.g., he knows the stiffness
of steel beams, the tensile strength of steel cables. and how much weight a
reinforced concrete column can carry.

Now in computing, for an algorithm, what do I know about the resources it
requires? E.g., I just wrote a Web site session state store using TCP/IP for
communications, my own code to convert the TCP/IP streams to the 'messages' I
needed, and Microsoft's .NET collection class SortedDictionary to store the
pairs of session keys and session values. So, how do I know fast my code will
be and how much storage it will need? That is, could I get data on TCP/IP and
SortedDictionary so that I could tell before writing and running the code?

That is, do I have solid engineering information about the components I used
that will let me know, before writing and running the code, the final
performance of my software?

NO!!!

Instead, about all I can do is run the code and measure the execution time.
For the storage needed, I don't have a good solution even given the running
code.

So, by analogy, if bridge building was like software writing, then a bridge
engineer would not know how strong his bridge was until he built it and tested
it with loads.

So, net, the bridge designer can 'engineer' his bridge just on paper before
any construction has started, but I can't do the same for my session state
store.

Again, a big difference is that the bridge engineer has detailed engineering
information on his components and I do not.

~~~
davidcuddeback
You make a very good point. I had to do a trade study of different
microprocessors (for embedded software) when I worked at a more engineering-
focused organization, because one of our requirements was that a certain
algorithm had to complete in under 30 seconds (or something like that---I
don't remember the exact time requirement). One of the things we had to do was
try to quantify how fast the algorithm would run on each processor, which as
you mentioned was nearly impossible.

We ended up looking up the MIPS [1] and FLOPS [2] for each processor, whether
it supported SIMD instructions, and how many pieces of data its SIMD
instructions could process in a single instruction. Some processors didn't
support floating point math, so we had to estimate how fast it could be
emulated with integer registers. Then we had to have some formula to estimate
the run time based on this data and the nature of the algorithm (what
percentage of the code uses floating point vs integer instructions, what
percentage can take advantage of SIMD, etc).

The problem with this is that even the published performance data, such as
MIPS, aren't a measure of a single attribute that we can apply in any
meaningful way. For example, MIPS is affected by clock speed, which
instructions are executed (some may execute in a single cycle, others take
several cycles), branch prediction, and cache coherency. How do you quantify
stalled instructions? The final execution time is a result of an interplay
between the hardware's characteristics and the algorithm's characteristics (as
compiled by a certain compiler) over time.

Perhaps a more appropriate approach for software engineering would be
statistics. Given normal distributions for MIPS, missed branch predictions,
etc, similar characteristics of an algorithm, and perhaps the language and
compiler used, then maybe we can give a confidence interval for an algorithm's
run-time.

But like you said, in many cases it's probably easier (and cheaper) to just
build the algorithm and then measure it.

[1] Millions of (integer) instructions per second.

[2] Floating point operations per second.

[3] Single instruction multiple data.

[4] Not to down-play the difficulty of that task. I'm sure it's very
complicated as well.

------
eswangren
I am first and foremost a software guy, but I work in a systems group. I write
hardware device interfaces. I solve problems in the physical world. Motion
control, digital imaging, electronics. Many of the problems I solve on a daily
basis are problems of physics, yet I solve them (mostly) in software. I think
the term "software engineer" applies here. Let's not forget that there are
many, many engineers just like me who do not write CRUD and web apps every
day.

