Slashdot Mirror
How Software Engineering Differs From Computer Science
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."
Wouldn't it still be as much a science as say... human psychology?
How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.
sudo mount --milk --sugar
Look, there is nothing wrong with being a programmer. Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.
No engineering degree = no engineer.
You need more of it.
Help stamp out iliturcy.
Going by the wikipedia definition decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then? ie something that you acquire on your own rather than something that can be formally taught or imparted as training? Makes you wince when you see all those job adverts asking for programmers to work in their "engineering departments"... Disc: I'm a coder myself, working in a structural engineering environment, so watching people design buildings around me feels more like "real" engineering... Go on, mod me down now.
You need a choo choo train for that
Humans are not maths.
.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.
Trying to associate Microsoft with "fun" is like trying to associate Satan with aromatherapy. -Tycho
If you're an X Certified Y Engineer, you're a technician.
If you can be counted on to design a system that reliably works without killing people, you're an engineer.
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.
If you can't do any of the above, you can always check bags at LAX for $150K a year.
If you can't get bags from the trunk to the belt, you might consider a position in middle management.
Help stamp out iliturcy.
Here is a formal definition of a Computer Software Engineer occupation, according to the US Department Of Labor:
"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
The author of the article should study a Noble prize-winning work "Administrative Behavior".
There is nothing secret about human cognition. The fact that software engineering relies on human resources and not on binary logic is in no way a limitation. Many modern algorithms rely on heavily on probability and work with uncertainty. Herbert A. Simon built a solid framework for understanding human decision making process. This framework is just as solid as mathematical formulas behind computer science.
So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.
Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter. To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.
Anyone can write a small program. You can fit 20 generic programmers in a room and have them each write a small program. You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.
One or two really good programmers will probably out-produce 20 people that "know how to program".
How many amateur painters do you need to create something like the sistine chapel?
Just because most people can't see the art that allows large programs to work doesn't mean it's not there. In fact, most people can't tell any type of good art from bad without some training.
A computer science graduate creates the perfect program, then a software engineer goes and breaks it by making usable.
I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.
Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.
So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.
One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.
Jilles
One is not engineering. The other is not science.
Reminds me of Martin Fowlers "A New Methodology" paper.
http://martinfowler.com/articles/newMethodology.html
Connell titles his article "Software Engineering != Computer Science." He later proposes Connell's Thesis, "Software engineering will never be a rigorous discipline with proven results, because it involves human activity."
I would suggest that the article's title reveals why software engineering doesn't have "proven results" in the sense that Connell means. It's not due to human activity. Rather: engineering != science. "Proven results" (i.e., a set of results logically derived as part of an axiomatic system) are more characteristic of a scientific field than an engineering discipline.
Engineering applies and relies on science, but is not science, per se. Mature engineering fields have standards and codes of practice, both science-based and empirically derived. When/if software engineering matures further, it is reasonable to expect such standards and codes to develop.
I think SE and CS are overlapping disciplines populated by people who tend to analyze the things that overlap and make (sometimes unnecessary) generalizations. Thus, it's natural that people in both disciplines make misguided attempts to define the relationship when in fact there is no stable relationship at all. It simply depends heavily on what you are doing. I could ask endless other similar questions, like: what's the difference between a musician and a composer? One can be the other, and one doesn't necessarily have to be the other, and one can be made better at one by learning about the other.
I've always compared software development to architecture in that you can give a specification for a building (size, floors, x rooms, etc) and you can get multiple designs that fit the specification but a great architects design will always stand out.
Sometimes I look at code and it just does n't "feel" right, sure it may work just fine but I may not like the design choices taken whilst sometimes I see code that is designed so well that the peices fit together seemlessly (not that often I'm affraid).
...is about a 1000x difference in cost per line of code. There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical. Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.
In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
The TFA, and any other such articles, amount to nothing other than navel
gazing. People who think they are a scientist/artist/whatever, thinking it
makes them more leet if they are able to exclude others.
The elitist attitude of contemporary science is something which I hold in
extremely deep contempt, to be blunt. Programming might not be considered a
pure science, if they want to try and claim that anything that
human beings do is completely free of emotion. Nothing does, so by that
definition, nothing is a pure science.
If you focus on the purely mechanistic/mathematical aspects of programming,
that can be considered science. If you focus on the emotion, or the level of
inspiration which sentience is considered a prerequisite for, it's an art.
Use whichever term for yourself that you want, or better yet, just be
you.
Remember Napoleon, people. The greatest Emperors crown themselves.
There toward the end I meant to post this Zen summary:
After all that you begin to realize that the more you know, the more aware you are of the vast expanse of things you don't know. And then I arrive at what you said in 16 simple words, by a long discussion. I guess you're smarter than me.
Help stamp out iliturcy.
Seriously. CS asks questions of the form will X accomplish Y? Software Engineering asks questions of the form "what is the best way X to accomplish y"?
Nothing to see here, move along.
... is that the Halting Problem and (verification of) Semanic Correctness of a program are formaly indecidable.
Some of these same old complaints exist with hardware too. It takes humans to detect the "bugs" in a circuit layout or to quantify how adaptable/modifiable it is (ie, maintainability). There's guesswork involved in figuring out how much to over-engineer something, finding the cheapest part that does what you need, crossing your fingers that a vendor doesn't discontinue a component. Hardware engineers may take a more rigorous approach than the typical software grunt, but it is still a human endeavor. Otherwise we couldn't have nearly so many board revisions and software wouldn't be used to mask over the hardware shortcomings.
The biggest problem with software is that it is easily malleable. We'd have far fewer bugs if it were treated like hardware that couldn't just be tweaked in the field if something is wrong; we'd be given more time to finish the designs and implementation, the testing would be built in and mandatory, nothing would be declared finished until several eyeballs looked it over and even then that would just be the initial prototype, and we'd have outside testing companies verify the solution for compliance with regulations. When software is malleable it's really hard to tell the bosses "sorry, we can't make that change" or "we can't ship this week because we added a bug fix and have to retest." Actually the same pressures exist in hardware (and other engineering discliples) it's just a lot more common with software.
Can't seem to find the blog/article, but thought Carmack posted about being a game developer was akin to wearing different types of hats:
- architect (designing)
- engineering (building the program)
- scientist (diagnosing bugs)
I know this topic has been discussed back in 2004...
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=182392
The old argument of knowledge vs inteligence !
Knowledge = the ability to REMEMBER answers to standard questions to pass exams.
Inteligence = the ability to understand and solve problems and be able to find answers ( e.g. IQ)
The 2 have no direct link - I would rather a person has the latter than the former but that's rare with societys obsession with memory based qualifications
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.
I'm struggling to see how aeronautics and aircraft have anything to do with cars.
I personally like the term software developer; though, my company formally calls me a software engineer. I am reading these comments about defining software engineering/development and it is obvious that it is difficult to quantify this discipline in terms of any other discipline. Software development is an inherently unique endeavor that requires I wide range of abilities and ways of thinking to solve difficult problems. Sometimes it requires rigor and a deep understanding of mathematical concepts. At other times it requires artistry and extreme creativity. And yet at other times it truly feels like working the line in a factory. It is beautiful in its exactness, many times revealing unexpected consequences. The latest US financial crisis has been contributed to unexpected consequences relating to software written in the 80's and 90's. At its core, however, is the goal of automation and thus freedom. We automate so we are free to perform other, hopefully, more desirable tasks. In order to accomplish this, software developers must learn about processes, machines, relationships between abstract concepts, communication, etc, etc, etc. Most importantly, however, we get to learn about people, learn about ourselves, and in the process learn about new things to automate
Let's face it. Most (if not all) programs we write are "made-to-measure" software, not mass production programs. You need craftsmen for that. Artists are usually only interested in the looks.
Software development is a skill that can only be trained. Trained to think like a hacker, to think like a newbie user, tothink like a client (client!=user), to know when to optimize and especially when NOT to optimize, trained to think in modules and their relations (I encountered far too many programmers who have difficulties with this). Trained to think in responsibilities. Trained to abstract. Trained to trust the unit tests. Trained to write them.
A good programmer is a craftsman. Someone who can build the wish of a client not exactly as the client has sketched it, but as a robust and working structure that does what the client wants.
An artist is someone who designs the famous "Z" chair and dares not sit on it.
A craftsman is someone who takes the idea of the "Z" chair and dimensions it right so it becomes a chair instead of an idea.
Software Engineering = fashion
Computer Science = maths
Simple. Nuff said.
Zen tips: Pay attention. Don't take it personally. Believe nothing.
Yep to me Software Engineering is more like Design.
:).
The Architects design stuff, and the Builders build it.
The Programmers design stuff, and the Compilers build it.
The trouble is too many people don't get it and manage software projects the way they manage the Build phase of a civil engineering project. When they should be managing it the way they manage the Design phase.
The build phase of a civil engineering project can involve scores of workers and heavy machinery.
The build phase of a software engineering project involves the programmer typing "make all" and going to fetch a coffee.
The big problem:
Civil Engineering: build phase costs 10-100x design phase
Software Engineering: design phase costs > 1000x more build phase
And that's why Management ends up shipping the "plastic models/blueprints" as v1.0 since they compile and kinda work.
How software engineering differs from computer science is similar to the way civil/mechanical engineering differs from math.
Engineering does involve math, but a lot of times you don't really do a lot of math - something else does it for you
Same for software engineering, 90% of the time you aren't doing the "pure CS" stuff- sorting algorithms, info theory etc.
You're doing stuff like figuring out how to talk (and what to say) to some database or Active Directory, or whether the API for something is documented (correctly) or not. Or creating a brand new protocol that is not too inefficient and mere mortal programmers can use without screwing up.
Writing source code is craft, making source code executable is engineering.
-- i drop mine in braille so you blind cats can read me
I agree with the author of the article, there are two levels in source code. On the one hand there is the formal side, the syntax level, if you will, which can be quite simply checked by tools. As programming language standards leave certain things undefined just because of the infinite amount of combinations in a language, so do compilers and linkers also. Static analysis tools, like lint, are much more nitpicking and try to uncover probable programmer mistakes for example through uncommon usage of certain structures.
But there is also the higher semantic level present in the source code. How well does the source code express its intent and how well is it structured. That is only directly visible internally, but does most likely have larger than generally understood indirect effects externally. The problem with software engineers is that they listen much too much to what the customers, testers and managers have to say. And all of them focus only on functionality. Most engineers also like to see something working and sometimes they do anything to get something working. Clarity and meaning in the source code are secondary concerns.
The results are clearly visible.
Software systems are working, kind of, but they cannot be changed too readily. Software isn't soft at all, because its internal clarity, maintainability is compromised. Using only simple names for variables (tmp, i, cnt, ret_val, status) makes code not readable, as an example. How much bad naming hurts the understandability of a piece of code is not known but is probably underestimated.
There are certainly rules that could be used to limit the chaos in source code without limiting the necessary creativity. There are issues that 1) are Missing from the source code, 2) Extraneous, 3) make Risky assumptions, or 4) cause Chaos. Some examples:
1) Magic (hard-coded) numbers
2) Comments that repeat what the code clearly says
3) Not checking a pointer for NULL before dereferencing it
4) Nesting too deeply
The funny thing is that such things can be easily checked manually, locally within functions, on paper and massive amounts of findings can be made in almost any programming language. Ticking code (or marking rule violations) shows that almost all software developers are neglecting maintainability in their code. Tick-the-Code is one way of triggering refactoring, and improving the design of existing source code. For more information, check out www.tick-the-code.com.
If having humans 'central to the process' is an issue, that rules out medicine, psychology, sociology, history...
Am I part of the core demographic for Swedish Fish?
This article could have been renamed to "Why I chose to major in Computer Science instead of software engineering" and it would also make sense.
199307 Engineering Times - Will High Technology Bring Engineering Disaster? [unverified software applied by unqualified users]
199409 Scientific American - Software's Chronic Crisis, W. Wayt Gibbs [software is being written but not by programmers]
199409 IEEE Spectrum - Judgment's Subtle Presence [replacing the decisions made by people with pre-programmed ignorance]
199703 IEEE Spectrum - Reflections on Complexity, Robert W. Lucky [just because you can does not mean you should]
199707 WIRED - Digital Obesity, Nicholas Negroponte ["personal computers" have never been people friendly]
199802 WIRED - Productivity Paradox [the numbers, folks, where are the numbers to back up the continued spending?]
199707 IEEE Institute - Software Engineering [accreditation of educational programs for "professional" programmers]
199800 Walking on Thin Ice by Peter de Jager [how the Y2K problem was created by the bureaucrats, not the programmers]
200004 US NRC - Digital Instrumenation Research Plan [the emperor has no software quality assurance program]
199907 US NRC- 464th ACRS - Commentary by Dr. Graham Wallis on RETRAN-3D [only "real professors" know what is correct way to "engineer"]
200502 US NRC ACRS Sub-C on THP - Commentary by Dr. Graham Wallis on TRACE [user manuals generally suck - DUH! so do most textbooks]
199907 No High Tech Training - The Financial Times by Rebecca Christie [a partial explanation of the productivity paradox]
200503 How computers make kids dumb - Andrew Orlowski - San Francisco [the title says it all]
SE has little to do with software. It has become mainly software project management. Software projects are disaster areas because inexperienced people look for gimmicks instead of putting in the 10,000 to 20,000 hours to become proficient. Just look at the job ads looking for "Senior developer with 3 years experience." Software used to be built by some brilliant people before CS and IT degrees existed. Most had degrees in physics and math or sometimes oddly enough - music. A few had no degrees st all. As computing has become more of a mainstream industry, most recent programmers have little knowledge of CS issues relating to simplicity, languages, algorithms, race conditions, etc. they get "certifications" from vendors! They just chase fads, throw everything in a pot and hope OO will organize it. They also seem to have little knowledge of basic engineering such as minimizing part and technology counts, orthogonal structures, neatness in design, etc. Now, I often do projects where I beat teams of 20 or more by myself. What's wrong with this picture?
You can learn the roman numeral system inside out and be the worlds leading expert on it but you can never do with it what can be done far more easily with the Hindu-Arabic Decimal system. A common introductory algebra student can by far exceed the limitations of doing math with the abstract Roman Numeral set.
The Decimal system allowed us to use "nothing" to hold value. The Zero place holder....something so simple, yet so enabling...
Who'd thought "nothing" could be so power enabling?
The same holds true of Computer Science and Software Engineering.
And again we are at a point of needing to recognize a real value of something that seems so unreal or foolish sounding.
Abstraction Physics, but how can the abstract be physical?
Not only can abstractions have a physics to them, but without the physical, abstractions cannot exist at all. And it is the physical that enables the creation of abstractions, a physical reality that does move in the process of making and using abstractions.
This is where abstractions and physical reality meet, where abstract ideas are converted to physical effect and hard reality.
What you are reading right now is an example of abstract conversion to the physical. From my mind to my fingers on the keyboard to the computer and over the internet..... to your screen where its being input into you and your mind. And if it were instructions to do something and you did, like make a paper airplane ...... thats all physical...
Just as there are definable atomic structures in the physical realm getting more and more refined, so it is with abstraction and genuine software engineering in dealing with abstractions and their unavoidable physical creation and use action constants.
These constants are identified and defined and by nature are so inherent in our human functioning that we don't even think of them..... However, computers are not human and they don't, unless we program them to. And we haven't yet done so from a POV of Abstraction Physics such the understanding would be as common and applied as the Decimal system is today, instead of roman numeral based mathematics.
Genuine Software Engineering should be making the task of programming easier for all of us. But it seems stuck, to use the analogy, thinking in terms of roman numeral mathematics. Physicist identify, define and refine our understanding of the physical, but abstractions, though we are the absolute creators of these, there is still the unavoidable and unchanging physical reality action constants of abstraction creation and use. And it is this that is the solid foundation upon which to build genuine software engineering.
The proof of the action constants is simple: Try not using them.
Mature engineering fields have standards and codes of practice, both science-based and empirically derived.
How is science-based != empirical?
It's math (and the math-ish parts of CS) which stick out as the sore thumb, in that we think of them as science but their practitioners occupy themselves with proofs rather than experimental evidence.
Math (and CS) are the oddballs, not the set {every other science}. Or do you think that math+CS got it right, and physics, chemistry, biology, astronomy, medicine, geology, (softening up) economy, archeology, anthropology, sociology, ethnography, history, psychology, ... got it almost right but still has that unfortunate aspect where they need to look at the real world to verify their ideas?
I'm currently pursuing an accelerated masters in computer science, I may be naive but i feel my view is valid. Open source is the future, well commented and the most efficient code should be made open source. Why rewrite code that has already been written efficiently? Allowing access to well written and commented code to the masses will allow for much more competition between coders. I understand it is not the easiest of jobs, but wouldn't it make it easier if coders had some sort of universal code library where the best(efficient and stable) code is up for use to create great applications and is also up for optimization and improvement?
There is no other definition of socialism valid for us than that of the abolition of the exploitation of man by man. - E
Whereas computer scientists go into research or teaching - to produce more computer scientists.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Oddly one one has raised the most simple of issues at the heart of all software development, the reality that the majority of software development is with the resolution of a wicked problem (http://en.wikipedia.org/wiki/Wicked_problem, problem where you can only get the input parameters by solving the problem first), this is in stark contrast of other engineering disciplines, with System Engineering being the only one that comes at all close.
When you look at the various engineering disciplines, they problems they are trying to solve may be complex and difficulty, but fundamentally the input parameters and expected output are known. Not to be trite but there are only so many ways to build a bridge.
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
I have my BS in Computer Science, am 1 course away from having my MS in Computer Science, as well as have 15 years experience in general IT with a focus on Network Security.
My BS in Computer Science was nearly 100% coding languages and techniques. My MS has had some coding in it and I would say that any computer scientist should have a strong grasp of coding. But, when you look at Computer Science as a discipline it should be these new undergraduates with an IT degree that do the coding jobs. This distinction didn't exist when I was getting my undergraduate degree, there was no IT degrees.
After going through my MS in Computer Science I have realized the discipline of Computer Science to be what it really is and that is applied mathematics. I am hoping that the IT industry will appreciate my vast knowledge of how computers work that I gained during my graduate studies, though I may not put that knowledge into whatever daily tasks I am responsible for. Looking at my background and education the best fit for me in the IT industry would be as a CIO or CTO. Though, I'm sure those jobs are a rare and of the type where you have to know someone.
Computer Science is just that a science. Not only that a mathematical science. I always wondered why people got math degrees, being they don't have a direct career path for them, other than academics itself. Now, I look back and realize I'm about to have a Masters in Applied Mathematics (Computer Science). How will that affect my future? Only time will tell. Like I said I got 15 years experience with my BS in Computer Science (Programming) and thankfully programming has never been my primary role during my professional career.
I'm at a crossroads, do I go back into the "real world" and see what I get for my upgrade to Masters in CS or do I stay in the academic world, get my Ph.D. and teach CS? Teaching pays a lot less but there is more job security.
But, one thing is fore sure I won't write you a program for the same reasons I won't fix your computer. Not that I won't code something if doing so makes my job easier or my company more efficient but I am a Computer Scientist and not an IT guy. So, you'll have to find someone else to change the toner in the printer.
There will always have to be people in the loop in all stages of program development but I think we have come far enough where the IT guys should be doing that and the Computer Scientists should be doing more advanced work. Let the secretary change the toner.
The only way people will be taken out of the loop is if someday Computer Scientists learn enough knowledge to create sentient beings, with an intelligence of its own, through a combination of hardware and software. Notice I said intelligence. Artificial intelligence is generally used incorrectly. Computer Science is currently at a stage where we cannot even simulate intelligence accurately. But, if we ever do create intelligent computers there will be nothing artificial about it. Once that happens it's likely that we will no longer be the most intelligent beings, we know of, in the universe. By Definition if we can create something smarter than ourselves then that something would be smart enough to create something smarter then their selves. Though, I don't think this will lead to a Matrix like scenario. Why do most people always imagine the worse case scenario? Though IMHO we don't even have to worry about such an event, unless it somehow happens by accident, because Computer Scientists cannot even define intelligence to any degree, never mind understand it enough to write intelligent code.
ANYWAYS, if people keep treating Computer Scientists like lowly IT guys we might just have to stick a 'pointer' into your eye.
Plus being a computer scientist I get the advantage of random implied youthfulness. That's why I was born Jan, 1970 and am currently 27 years old. It's all due to applied mathematics. How many Java or .NOT programmers understand why?
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
The statement that software engineering - which is a mislabel - cannot be a rigorous, formal system is so obvious that it might as well be one of those things we never think about until we have to and when we do think about it it's intuitively obvious.
Consider what will happen when you die, there are only three possibilities: You exist after you die and you like the results; you exist after you die and you do not like the results; you do not exist after you die. All three possibilities are equally valid since we have no evidence of any of them. If as it turns out, that when you die you cease to exist, it is not something you need to worry about. Now, the thought probably terrifies you - it used to terrify me, too - until you realize something: if you cease to exist, you will know nothing. You'll never know that you don't exist.
So consider the conditions of the existence of software. Software is always perfect and is always the same, it never changes. It does not rot, rust, age, get moldy, crumble, break, shatter or fail. It never needs maintenance, lubrication, cleaning, sharpening, polishing, repair or replacement. As long as the hardware that copies it makes identical copies, it is perfect and always will be perfect, except for the extremely rare and unusual case of deterioration of the storage media due to cosmic ray damage. Which can be detected by mathematical algorithm, in which case, if there is another source, another perfect copy can be made and it's right back where it was. Software is never defective and can never be defective other than the case I've given of the rare possibility of cosmic-ray damage to media or hardware failure in copying, and thus it never needs change, modification or updating.
Every year, every country makes changes to its tax laws. Any software which must comply with those new changes has to be changed according to the decisions of tax accountants and lawyers as to what is needed to be in compliance. If you have a cellular network and want to add new features, you have to modify the software - in the switches, the handsets, the gateways, and/or all of these - to be able to enable them to offer new features. In both cases the software needs updating.
Both statements are true, but you might ask how they can be when they appear to be conflicting. They're not, and I'll explain why.
Any software package, from a 1-line APL function to a 20 million-line COBOL behemoth application suite that runs a trillion dollar bank, large insurance company or government agency, only requires maintenance or change because in someone's subjective opinion it needs a change. A bridge needs replacement when it collapses or when it is beyond its useful life; a building needs replacement under the same circumstances. A piece of metal furniture needs replacement when its structure rusts into dust, fails or is unable to support a load due to metal fatigue. These are objective facts, either the structure is usable or it isn't. An engineer can determine by experience and judgment that the structure is at its lifespan limit or can point to signs of physical rust, deterioration, or structure failure indicators that prove their opinion.
Any declaration that a software package needs updating, change, or replacement is strictly based upon the subjective opinion of someone saying that it needs the work. All software change is the result of some person's opinion that the change needs to be made and have no basis in reality except their opinion. Their opinion is correct if you agree with them or if in your opinion you can't disagree with their opinion. They may be correct that because of errors in how the software performs its desired function, need for new function, or need for changes in existing function, the software needs change, replacement or updating, but they can only be "correct" because it is considered that in someone's opinion they agree with their opinion that the change is needed.
But the claim by someone that a software package needs cha
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
I've always thought (and I think there are some Scrum related papers to back me up on this) that the instant malleability of software design has substituted for formal practices.
There's nothing as malleable in the real world so we don't know how to formalise it.
Instead, on most of the system I've worked on, management have tried to introduce formalities just so they feel happier - when there's no real point.
Example: I'm trying to figure out how to strip UTC from a bunch of fields in a system - make them date only instead of time-zone aware date-time. The answer is easy (change the data type), the analysis is horrible (find all the other fields and operations that are touched by the field concerned), but the management overhead is outstanding - I've had to write two document, an hour long presentation, and a video-cap of a demonstration, a risk assessment probably too; and still people won't leave me alone to get on with it.
Software engineering is a part of computer science. Everyone who thinks computer science is only formal methods is totally wrong. Its like saying theoretical physics is physics but experimental physics is something else than physics. Computer science has a core based on formal methods. This core comprises logic, turing machines, grammars, L-systems, petri nets, my-recursion all the other thinky stuff. Most of that stuff was borrowed from other disciplines. Languages were borrowed from Noam Chomsky and the linguists, the Turing machine was developmed by A. turing a mathematician, L-Systems comes from biology, logic from philosophy.
Around this nice set of formal methods, we computer scientists developed different ways to use them to solve real world problems. our job is to develop tools and methods to process data and information. We do this with formal methods. However, to find out what the information is and what we shall do with it, we have to ask the user. This is requirement engineering. therefore we make interviews, give out questionnaires and read literature of other disciplines. So interview techniques, questionnaires, and text analysis become part of our discipline's tool-set as well.
And the development of software is a complex process. Therefore we thought it might be helpful to use the shoes we made for other for ourselves. This is also part of software engineering. And therefore it is part of computer science.
As a degreed engineer with 30 years of work in computer hardware and software, I firmly believe there will be no such thing as a "Software Engineer" until such engineer has a "PE" after his/her name. That's "Professional Engineer" (wiki it); a responsible party who can be put in jail if the software kills someone. There's nothing like the threat of punishment to put rigor in your processes.
I used to laugh when programmers started calling themselves "software engineers". It reminded me of the joke about "sanitation engineers". Now this kind of title inflation is the norm, but don't kid yourself, you are not a real engineer just because it says so on your cube entrance.
Most undergraduate students don't have enough time to learn the basics of computer programming, never mind software design.
As I stated in a separate post in this same thread people with IT degrees should be doing the majority of programing. When I got my undergraduate there was no IT degree, if you wanted to work in IT you got a BS in CS.
In a perfect world, Computer Scientists (like myself, MS in CS) would be doing research and developing new advancements in CS.
Regardless, in graduate programing courses you learn things like how to mathematically analysis different algorithms to determine which are superior. How much of this goes into modern coding? Very little, if any.
Cheaper, faster, easier is the motto of most programs written today. This increases with the more business management that gets thrown into the mix. That's how something like MS Windows Vista comes into existence. Give any real Computer Scientist the project along with the right to choose a developmental path and almost all of them would opt to scrap it and start over. But either extreme is bad in one we get crappy software and the other nothing is ever released. Currently we lean towards crappy software because hardware has developed so much faster than software. If some physical law, universal law, prevented computers from having over 1 GB RAM and 100 MHZ CPU, then the focus would have shifted and I would still have 8 programs running on my computer and would be experiencing the same computing experience I currently am because programmers would be writing better code.
So is it engineering? In it's current incarnation, no. Could it ever be considered engineering? Sure, but it would take a massive shift in the software development life cycle.
Personally I cannot wait until Moore's Law becomes Moore's Theory when it breaks because of some physical law stalls hardware development. Then maybe we will see some good code.
Plus, isn't an idea supposed to be a theory until proven to be a law? I mean does anyone really think it will continue indefinitely? I bet Moore didn't even think so. It seems we started calling it a law and it will continue until proven to be a theory.
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
The way I see it.
... and the customers often buy it :).
Civil Engineering:
Design Phase costs about 10% of Build Phase
Build Phase involves tons of construction workers and heavy machinery.
The blueprints and plastic models are way cheaper to make than the Real Thing.
Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.
Software Engineering:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.
The plastic models cost as much to make as the Real Thing.
Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design...
It should be no surprise then that the plastic models regularly fail.
But maybe I'm seeing things wrong?
BTW I suspect that a Civil Engineering Design phase is managed a bit differently from the Build phase. Still, I'm not an architect or civil engineer so what do I know.
"A practitioner of comp. science for 10 years" eah? Well, if I count my total experience in CS then I have been at it for over 35 years, pretty good for someone 27 years old right? What degrees do you hold? When did you get them?
Do you realize that you stated you have worked with computers for 10 years even after I told you I had 15 years of top level IT experience, not counting any time obtaining my advanced degrees in the subject. The only thing we know about you is you have a Slashdot account! Pathetic!
When I do graduate with my MS in CS I will likely know more about Computer Science than the professors teaching me. This is the same for all the graduates, with a few exceptions because we have a more modern education in the field than they do. So, the newer a degree the more it should be respected.
Plus you sound like a idiot programmer, who loves his .NOT programs, and makes less than my pool guy.
As far as being finished, I hope to never finish learning. That's when your education starts to degrade.
I assume since you are inciting flames that you have finished learning long ago and would have to pull your head out of your but to even be qualified to get me a cup of coffee (1 sugar, 2 cream please).
I don't "know everything" and I thank God I don't! If I knew everything there was to know about CS then it would likely bore me.
Though, I could do without people like you spouting off flames that don't even support any of their arguments with any evidence or alternative perspectives.
Since you haven't identified what you do, if anything, I can only assume you are a programmer that got offended because you have not caught on that your job is the bottom rung of the IT world, and only a learning tool for actual computer science.
In that case, I'll close with go fork(); yourself!
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
Engineering principles can be applied to software (even the wishy-washy stuff like requirements and usability) but nobody ever does it because of the deadline. The product needs to go out the door yesterday! To meet our contractual requirements or be first-to-market or patch the gaping vulnerability introduced during our last frenzied hack-fest.
The difference between other engineering fields and software is that in, say, civil engineering or architecture, production is expensive and fixing errors post-production is ridiculously expensive. Nobody wants to put up half a skyscraper only to find that the foundation is wobbly or the main structural elements too weak or the design too top heavy. So it's sound business practice to do a lot of rigorous, mathematically-provable checking and double-checking during the design phase, well before anyone puts on a hard-hat let alone builds something that might fall down.
With software, it's the reverse -- the design takes all the time, and the production is super cheap, and changing things after production isn't usually that bad. Even if you have a large and expensive deployment, it's still usually feasible to change the software long after it has been built. And in the typical case, the business use doesn't justify a rigorous up-front design. Sure, fixing a defect after the code is in use is always harder than fixing it beforehand -- but that has to be weighed against the business value of having "good enough" code, sooner.
So, software engineering will never really become a rigorous field because there's no business reason for it (as opposed to fields that build physical objects, which have business pressure to be much more rigorous).
-- 77IM
Student: Is it true that the foundation of the universe is paradox?
Master: Well, yes and no.
ABET recognizes Software Engineering as a legitimate engineering field. Just sayin'...
"Ah, engineers, the oompa loompas of science"!
Programmer, Software Engineer, Computer Scientist, Software Architect. The title depends upon your level of insecurity. Same with Computer Science compared with Software Engineering. Was Michael Faraday not an inventor of electronics because he didn't use calculus? The truth is that there are good, bad and ugly practitionares of computer engineering science. The ugliest of all think they are good.
I believe some places up in Canada are now doing PE certifications for Software Engineering as well. Last time I researched this, I believe Texas was going to do the same thing for some reason failed. But PE certs for SE will be coming in not too distant future. Will that finally shut up the "software engineers are not real engineers" crowd? Probably not. I find the kind of people who even make such complaints are usually "paper engineers" anyway and haven't done any actual real work "in the field" and their entire self esteem is built on having a degree that says "engineer" on it. IMHO, just because your degree says "engineer" on it doesn't make you a "real" engineer either. After working in the field for about 7 years, with many different kinds of engineers, I have to say I've met quite a few "paper engineers" during that time.
When I studied software engineering as part of my degree I found it quite painful. It seemed quite interesting and relevant but it eerily reminded me of the "soft" sciences I had to learn to pass school (foreign languages, biology, chemistry).
For me the most frustrating thing in computer science is the many programming languages, each of them offering one compelling feature or another. But as Paul Graham said: Languages evolve slowly because they're not really technologies. Languages are notation.
The problem is, that it is not enough to create a better programming language or integrate a missing feature into an existing one, because then you have made the problem worse by introducing an additional language. So what you really need to do (at the same time) is to persuade other developers to adopt your language by providing a notation which is "powerful" and looks "nifty". And that is where the human factor comes in.
Jeffery Fong, a NIST project manager, gave a talk at our school yesterday. (He's the one tasked with making FEM models of the twin-towers and modeling their collapse.) He summarized the differences between science and engineering as: engineering is science plus uncertainty and scalability.
If you accept this as being generally true, the question then is, is software engineering computer science plus uncertainty and scalability?
Take the proportion of your conversation that is mathematical jargon, divide by the proportion of your conversation that is computer business jargon, and add the product of alpha and the number of years you spent in graduate school, where 0 1, you're a scientist.
Try and see the sarcasm here. It's very subtle.
Help stamp out iliturcy.
It's not my fault the guy wandered into the thread at the precise moment I was pointing at the door warning "We're about to be invaded by rabid loons". If he wants to self-identify that way, that's funny.
But it's a nice day. Rather than sit here and argue about it I think I'll put my dog in the boat and tease some fish for a while.
/And yes, this is off topic. Thanks for noticing.
that one is easy. http://news.cnet.com/terrafugias-flying-car-makes-maiden-voyage/
I have written from the very lowest level ( microcode ) to the very highest level ( web scripting ) and everything in between.
So lets talk titles here, because that is really all this is talking about, really.
In all of this I have drawn on experience, technical publications, Worth, K&R and many other sources, and I have published some of the methods I have used. Am I a scientest, engineer, dreamer, artist, designer or am I all of these things?
Hey KID! Yeah you, get the fuck off my lawn!
I'm always amused by self-appointed slashdot experts when it comes to technology. "We can configure computers, therefore we know everything".
Computer Software Cannot Be Engineered
Norman Young
Computer software cannot be engineered because there is no science of computer programs. Science is essential to engineering. The application of scientific models through engineering judgment defines the essence of engineering. Computer programs, as mathematical objects, are not subject to scientific laws. Consequently, by definition, computer software cannot be engineered.
The application of scientific models through engineering judgement,defines the essence of engineering. Engineering itself involves the creation of useful artifacts. What distinguishes engineering from other creative professions is the use of scientific models in creating those artifacts. Engineering judgement chooses among a number of available models to use in solving a problem, balancing risk of failure with the effort of analysis. What characterizes engineering is the scientific underpinnings of at least some of the available models.
Computer programs are mathematical objects. In particular, individual computer programs are specific values in a discretely parameterized model of the computer that executes them. ill The physical computers which execute computer programs have scientific meaning, but the programs themselves have no physical meaning apart from the meaning attributed to them by the computer. Consequently, computer programs are not subject to scientific laws.
As purely mathematical objects, with no underlying science, computer programs and computer software cannot be engineered.
Mathematics is important but in itself not sufficient to characterize engineering
Mathematics is important to engineering but in itself not sufficient to distinguish engineering from other vocations [Davis. M.]. Engineering uses mathematics to express engineering problems, and to reason about the scientific models used in solving engineering problems. Specifically, all mathematical statements used in engineering have some physical interpretation, relating various quantitative aspects of a problem or its candidate solutions. The scientific basis of all mathematical statements found in engineering is part of what distinguishes engineering from other activities, not merely the use of mathematics itself.
In contrast, other fields use mathematics, but not necessarily in stating scientific properties about the physical world. For example, the commercial activities of accounting and finance use mathematics, but the mathematical statements used in these fields are based on conventions about the value of goods and services. Accountants and economists derive models based on these conventions and use mathematics to express ideas and reason about problems represented in these models, but the models themselves have no physical scientific meaning. The models and related mathematical statements only have meaning within the commercial conventions on which they are based.
Consequently, the use of mathematics is in itself not sufficient to characterize an activity as engineering. Permitting the use of mathematics as a sufficient basis to qualify an activity as engineering is the same as saying that whenever anyone is using mathematics then they are applying engineering. The statement must be further qualified. Whenever someone is using mathematics to reason about a scientific model in building a useful artifact, then they are applying engineering.
Engineering without science is craftsmanship
Like engineering, other professions use models and apply judgment to create useful artifacts. For example, many creative trades, from industrial design to pipe-fitting, use physical prototypes to analyse problems and evaluate alternative candidate solutions to those problems. These trades apply judgement in balancing the value and insight that the models provide with the effort of developing and analyzing them. Many professions also apply predefined models and conventional solutions manifest through the historical traditions of their respectiv
On the question of engineering, I believe it was Knuth who was once said that programming is somewhere between an art and a science.
That's about as accurate and precise an explanation as any, and he wrote it decades ago. Apparently, it took some people, like the author of TFA, this long to figure out what he meant.
Well! You are not going to get any science if you make fun of our weight and call us names.
Table-ized A.I.
Here's a similar blog-article:
http://www.geocities.com/tablizer/science.htm
certainly explains Slashdot's screwy CSS layout
-1 Truth too Painful
Computer Scientists are reductionists - If a problem is too hard to solve, simplify it by throwing some of it away, until what is left CAN be solved. The result may still be of some use.
Software engineers make systems for real world use - If a problem is too hard, throw another programmer on the fire.
FOSS engineers can reduce the problem and call it version
The difference between "Computer Science" and "Software Engineering" depends on the school, and nothing else. There is no standardized curriculum for computer science nor for software engineering. My own experience has been quite different from that of the author. At my school, software engineering is about applying the theory which is computer science, and software engineers are required to take the same courses as computer scientists as well as additional lab courses in which they learn software engineering best practices; by contrast, those who sign up for purely computer science are exposed only to the theory and often end up writing code in which variable names are enigmatic and uninformative (e.g. "alpha", "beta", "theta") and which do not take advantage of good OOP design methodology.
Of course software engineering and computer science are different, but only in the sense that a square is a rectangle but not all rectangles are squares. Computer science goes FAR beyond software development/engineering and maintenance; and no I don't mean general information technology. For example, the hardest part of producing software comes before the development phase, solving the problem. Any engineer or team of engineers can take a solution and turn it into code but if they have no solution, it does not matter how much they know about .NET, JAVA, php, or whatever, they will sit around like every other person beating their heads about how to apply their discipline. There is no argument here. You have excellent computer scientist that can solve problems but aren't very code savvy (and don't really need to be) and you have software developers that can take a solution and bust out code as if they were acing some simple test. You then have people that can do both.
"Economics generally failed to predict the mortgage meltdown."
Um. No.
There were a *lot* of economists that were saying a decade ago that nothing good could come from the deregulation craze, and the almost total lack of effective oversight over at the SEC.
You want to hang somebody out to dry, go after the financial execs that did the stuff, and the government people that acted as facilitators.