-- Preface to the First Edition of Structure and Interpretation of Computer Programs (http://mitpress.mit.edu/sicp/front/node3.html)

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.

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.

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?).

You betcha, PEs are justifiably proud of the title.

We have sysadmins around here who call themselves "Microsoft system engineers". It bugs me, but title inflation is a Dilbertesque fact of life.

The actuality; the professor is correct. The circumstances of the situation just make for misunderstanding and an apparent disrespect for the medical doctors walking around, from the perspective of the medical doctors.

edit: changed the wording

Not to be too hard on you though; yes, the biggest aesthetic difference between hardware and software engineering is that with the latter, the cost of fabrication is essentially zero. But as described here: http://www.ics.uci.edu/~jajones/papers/p439.pdf

> The essential distinction between software and other engineered artifacts has always been the absence of fabrication cost. In conventional engineering of physical artifacts, the cost of materials and fabrication has dominated the cost of design and placed a check on the complexity of artifacts that can be designed. When one bottleneck is removed, others appear, and software engineering has therefore faced the essential challenges of complexity and the cost of design to an extent that conventional engineering has not.

So naturally the set of constraints is different than the ones with which hardware engineers contend, yet software engineers do fundamentally apply math and science to design products to meet hard, real-world constraints: Development time and cost, program correctness, time and space performance under expected load, reusability, and maintainability to name a few.

If there is a valid objection to the notion of software engineering as a "real" engineering discipline, it should be that a subset of the science upon which the discipline is based – that of software architecture – is at this point still underdeveloped and poorly understood, and as a result software engineers generally rely on their own intuition when it comes to architecture. (This in contrast to fundamental computer science, which is well developed enough that we can typically determine from mathematics or empirical evidence what kind of algorithm or data structure to use under given circumstances.)

But an arbitrary bias that engineers produce only physical artifacts does not constitute a valid objection.

Engineering is defined by the various international agencies and schools that accredit engineers, not Wikipedia. "Software Engineering" is a real engineering discipline in Canada and other places. The premise "An engineer's model must be tightly bound to the laws of physics and chemistry" just seems to be a construct of the author.

Engineering is about the practical application of rules, balancing factors like cost, maintainability and scope. Chemical, mechanical and software engineers do similar jobs, working with different sets of rules.

An exam based in physical sciences would be a great way for people with an educational background in physical sciences to stake a claim on software, calling themselves "engineers" while everyone else is a mere developer or programmer, putting themselves at the top of the field.

I majored in Math and have an MS in Industrial Engineering. I think that it would make as much sense to make everyone prove that they've passed courses in Abstract Algebra and Real Analysis, and take a difficult exam involving proofs about optimization and convexity to be a "software engineer." And this time, I would get to be on the top of the totem pole instead of people who have a more physics and chemistry based education! I hope it's clear I'm being facetious here - I just want people who do advocate PE style licensing to get a sense of what it's like when people from a different field start telling you what you need to know and do to practice your craft.

I do understand that there are software elements to engineering systems, and it might make sense to have some sort of licensing around it. However, I have yet to see a professional association refrain from severe "scope creep", using their cartel-like power to establish arbitrary and unnecessary barriers to entry to restrict entry and jack up prices.

Software is kind of like engineering, but I agree with the author that it has more in common with mathematics. Seriously, it would make more sense to require a degree in math and an exam in path than a PE exam. And it would not make sense to require this kind of math.

My take on it is this - I am not an engineer, what I do is not engineering, and the PE folks have absolutely no legitimate claim on what I'm doing.

Personally, I don't usually see people favoring the word "engineer" over programmer or software developer. As for myself, I see them as synonyms.

It's alot like doctor or lawyer, you technically can't call your self one unless you have a professional certification from the applicable engineering society.

I know when I graduated with an engineering degree in Canada you couldn't call your self an engineer until you were a PE.

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

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.

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

As you indicated, ACM would constitute as (a major) part of that push back, so I don't see the contradiction.

"Programmer" is someone who just writes code. They don't plan, organize refactor ... they write code according to someone's instructions. They can see that it works and debug issues, but they're not the "architects" or "engineers" of the system. The men doing the physical labor of building a ship aren't the "engineers."

"Software developer" doesn't have simplistic connotations to me, but seems to evoke something in non-devs ... as if I'm using lingo and being pompous.

"Software engineer" is someone who designs software systems and understands the impact of design decisions made from the bottom/back of the stack through the top/front. Perhaps, this being an industry of mental rather than physical labor, the engineer also fills the job of "programmer."

So in my mind, "engineering" is a way of thinking about and solving problems in any given space; it requires breadth and depth. But how do you quantify something like that in an industry that changes so rapidly, where someone can begin to grok concepts and "get their hands dirty" without ever having to approach the dangers out in The Real World? You don't want some random kid to think he can build a bridge, but he can certainly start writing software... and he can become "engineer quality" before he ever gets to a university.

I don't know that I've ever heard anyone call themselves "an engineer." That's nice. Does that mean you drive trains? That you design and build roads? I don't believe many engineers of the physical world variety can just just fields - a computer engineer is not going to build sky scrapers.

Stupid companies have titles and titles are associated with more pay and and more respect. It so happens that people who went to a 2 year technical school would call themselves "programmers" and then those who went to a 4 year college and worked for 5 years don't want to be called by the same label, so they have to invent something sounds harder to get, something more prestigious, so now they are "software engineers". Just like chemical engineers, it implies a certain difficulty of attaining this title, and it is used to differentiate the ranks. But it doesn't stop there, then there is more stupidity there is "Programmer II" vs "Programmer VI" vs "System Architect".

This is even more true in licensed fields. If you have a two year degree, your title will generally be "Engineering Technician", and not "Engineer". And you get to be on a completely different pay scale for the rest of your life as a result of the degree you obtained, even if you do the same work as an Engineer.

http://usmilitary.about.com/od/enlistedjobs/a/21.-uJZ.htm

For example (note "combat engineers" is in quotes):

"Military experience?

All branches of the military have engineers doing genuine engineering work. In this regard, the military is just like any other employer, and the engineering work experience counts. However, work performed by "combat engineers", electronic repair technicians, and so on is generally not true engineering work." [1]

[1] http://ppi2pass.com/faqs/qualifying-to-take-the-licensing-ex...

The liberal use of the term 'engineer' to describe technicians or mechanics does irk many in the engineering fields, however.

In Germany, the term is protected, so it is illegal to use the label without holding full qualifications, like 'doctor' or 'lawyer'.

Let's acknowledge that language grows and changes as new concepts are invented.

Yes, yes I would.

http://en.wikipedia.org/wiki/Architect_(disambiguation)

- third bullet down

http://en.wikipedia.org/wiki/Architecture_(disambiguation)

- look under 'Process Architecture'

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.

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

Doing so is called "industrial engineering".

Yes. None of these items, strictly speaking, qualify as Engineering work for purposes of licensing. If you are applying for an Engineering license, you will need to subtract these hours from your Engineering experience, and if a large portion of your day-to-day work consists of these tasks, then it may take you significantly longer to obtain your license.

It took me six years rather than the usual four to get my license as a result. Lunch doesn't count. Facebook doesn't count. Filling out expense reports doesn't count. Re-filling the paper in the printer doesn't count. Soldering doesn't count. There are a large amount of necessary non-Engineering distractions in any career, and none of these count.

It's true, my definition is US-based (maybe even based on a single state), and even more narrowly, it's based on US PE licensing requirements, which isn't even necessary for many Engineering fields these days. But at least I'm not dodging the question, here.

As an example, drafting is billed at a different rate than Engineering precisely because drawing in CAD itself is generally not considered Engineering.

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.

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.

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.

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.

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.

Software engineers definitely fall under this definition.

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

On what grounds were you "pretty sure"? Etymology is one of the easier things to corroborate online.

That's where I begin to say that computing comes up short as 'engineering':

The problem is that too often in computing the "design" work, just the design work alone, before construction, cannot really tell what the "practicality, safety and cost" will be. So, too often in computing we have to build the system and then test it to know what its "practicality, safety and cost" are. That was often the situation in the construction of medieval cathedrals: Some examples stood; some fell down; some on the borderline got weaker over time. Apparently eventually the strong cathedrals were built mostly drawing from experience, that is, closely copying what had already worked before. That technique is trial and error and copying and not really the 'design' of engineering.

If bridge engineering were the same as software construction, then just to know how strong the bridge was we'd just have to build the bridge and then test it. For rocket engineering, to know if it could reach orbit we would have to build and launch it. Indeed, instead, in rocket engineering we can determine the rocket trajectory that will put the maximum payload into the desired orbit.

I explained further in

http://news.ycombinator.com/item?id=4356303

in this thread.

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

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

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.

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

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

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.

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.

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.

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)

;)

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

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.

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.