How Software Engineering Differs From Computer Science 306
cconnell sends in a piece he wrote for Dr. Dobb's which "argues that software development will never be a fully formal, rigorous discipline, and the reason is that software engineering involves humans as central to the process." Quoting:
"Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science — perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software. The same is true for safety. Researchers have used some formal methods to learn about a software system's impact on people's health and property. But no discussion of software safety is complete without appeal to the human component of the system under examination."
Re:Is software "engineering" really engineering? (Score:2, Informative)
You'd be surprised how little "real" engineering involves "mathematical or physical analysis" sometimes. Most of the time it's more a matter of "do what we did that worked last time". Those people designing buildings are using a lot more intuition and estimation than you realize.
Formal definition of a software engineer (Score:4, Informative)
"Research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications. Set operational specifications and formulate and analyze software requirements. Apply principles and techniques of computer science, engineering, and mathematical analysis."
OutputLogic [outputlogic.com]
Re:Before we get all sweaty about terms (Score:3, Informative)
...
If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.
If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician....
Both describe a (natural) scientist. Mathematicians do entirely different things (they don't work with observed facts, they don't make postulates based on said facts, they definitely don't predict unobserved phenomena. That's all what science is for).
Re:Experience (Score:5, Informative)
If you think K&R invented functional programming, you're sorely mistaken, Go look up people like Peter Landin and Haskell Curry. Secondly, if you think that the C language book has anything to do with Functional programming, you *badly* need to get an education with regard to what FP is.
Re:Is software "engineering" really engineering? (Score:2, Informative)
"But Software Engineering houses most of its complexity in the actual complexity of the chosen language"
That's probably the reason why all my SE courses featured no code samples.
You really need to look up the difference between programming and software engineering before you throw up again.
Re:Experience (Score:3, Informative)
It's an interesting point, and because I can see a fair littering of good comments by you all though this discussion I'm intrigued - what did you mean?
K&R derived C from BCPL which was the non-hard-to-compile parts of CPL. The hard parts went on to become the basis of several functional languages.
Re:Experience (Score:2, Informative)
You're talking about Carpentry, not Planning. Architecture is made up of both - you have to be able to make a building that stands and has doors and doesn't fall apart. It's an entirely different human-centric side of the discipline to put the doors [i]where people want them to be[/i]. That's what TFA is talking about.
Software Engineering and Computer Science are not the same thing.
Computer scientists tend to make for really crappy software engineers. They tend to make overarchitected apps that don't meet the business need, aren't maintainable, and take years longer than planned.
What the stakeholder actually needed was a Visual Basic app that would have taken 3 months, been easy to maintain, and actually filled their business need. The app would probably have changed direction 1 month in, but thats OK - thats why you make mockups and lightweight proof-of-concept code to help steer them.
This is not a problem that K&R, Bjarne, or Turing addressed. This is software engineering. Read TFA.
Re:Experience (Score:3, Informative)
"Functional programming" has NOTHING to do with the existence of functions in your program.
That would be "strucutred programming", what K&R was doing.
Functional programming is A LOT more high-level.
C just a much easier way (than assembly) to organize your code in functions and data structures, plus a library to access basics of the system (libc).