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."
Perspective? (Score:4, Insightful)
Re: (Score:2, Insightful)
Software Engineering is trying 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 t
Analogy? (Score:3, Funny)
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.
Re: (Score:3, Funny)
Look at the wings on any fast car, and you'll see.
Re:Perspective? (Score:5, Insightful)
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.
That's pretty much how I think myself.
Engineering would stop being engineering if it becomes a science.
Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.
Writing software is a creative process, arguably even an artistic one.
Same with science. I'd say that in the respect there is not much difference.
The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors.
Re:Perspective? (Score:5, Interesting)
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
I think you're confusing (or conflating) science with mathematics. But don't feel bad; people do this all the time. Part of the reason is that science routinely uses mathematics as a tool, and the two fields are deeply intertwined. Scientists use math to help understand and explain what they're working on, while mathematicians routinely use scientific work as inspiration for new ideas to pursue.
But the "science" part is usually very much about the real world. It's the mathematicians who carefully avoid dealing with the real world, since that's not their job. The interesting part is how often the abstract, theoretical stuff that the mathematicians work on turn out to be very applicable to figuring out what's going on in the real world.
One of the problems with our terminology is that "computer science" is generally used for the abstract, theoretical part of software. This is misleading, because the subject really is a mathematical field, not scientific. If it were scientific, the computer scientists would be performing experiments and developing hypotheses to explain how software works. But that's not what they do; it's the "software engineers" trying to debug software that do things like that.
And this leads to the problem that "software engineering" generally involves doing things that in other fields would be called "science". In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design. With software development, this isn't generally true. An engineer designing a bridge or house or airplane can expect to work with detailed specs for all the available components. With software, the equivalent information is usually proprietary and intentionally hidden from the people building the code. Even in "open source" systems, the concept of "information hiding" is popular, and all too often this does mean that needed information is intentionally hidden from the person writing the code. So the software engineer is working with poorly-documented material, and must develop using processes that test and discover the properties of the underlying stuff.
Of course, there are some software engineers who don't do any debugging. But we know how well this works. Civil engineers might be able to develop this way, since they have access to full specs for their material. Software engineers can't, because they are kept ignorant of the details of lower-level stuff. As long as this is true, software engineering must have a large scientific component, to study and test the software as it's developed. They must constantly develop and test hypotheses about their code, in order to get it to function as desired in an environment that is mostly hidden.
Anyway, there's little chance of getting the terminology straight any time soon. There's no chance of software people getting access to detailed specs for the underlying systems. We even have laws in place that block the access to full information. So software engineering can't really be true engineering, and software developers will continue to spend large parts of their time acting as experimental scientists in order to debug their software. And they won't get much help from the computer scientists, who are spending most of their time working with the mathematics of the subject, while disparaging the real-world portion of their discipline as being "mere engineering".
Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use. But that isn't going to happen any time soon.
Re: (Score:3, Insightful)
Science and Religion really don't interact at all. Science makes an attempt to explain the world as observed through our own eyes (or instruments). Religion offers an explanation and where that differs from observed reality, assumes reality is wrong!
You can take the view that as we'll never know the truth about the universe that both are valid perspectives - but you can't say they're complementary in any way. Scientists don't need to 'work with religion' - they work with reality - and if reality coincide
Re: (Score:2)
After watching the ISO debacle approving microsoft's OOXML, I must agree with you.
Re: (Score:3, Insightful)
Why can't software engineering have more rigorous results, like the other parts of computer science?
(hint, engineering!=science, if you can't see the obvious, read your own article headline)
When it says things like:
No concept is precisely defined. . . . We believed that structured programming was the answer. Then we put faith in fourth-generation languages, then object-oriented methods, then extreme programming, and now maybe open source.
then you know it is even more confused, using debates about improvements in langua
Re: (Score:3, Insightful)
Let's rewrite your words and the original article's words a little bit:
[Electrical] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. Writing [circuit card VHDL] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [schematics].
[Automotive] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. [Designing steering wheels
Re: (Score:2)
You need more of it.
Haha. Probably...
Re:Experience (Score:4, Insightful)
Don't we all need more experience?
The basics are pretty simple. And by the basics, I mean where Niklaus Wirth [wikipedia.org] got his ideas for the mathematical basis [wikipedia.org] for algorithms, Alan Turing. [wikipedia.org]
Then we learn about functional programming from the guys who invented it: Kernighan and Ritchie [wikipedia.org]. Grok lex and yacc and we're halfway there. After we've written three or four languages we realize their purpose is to formalize our interaction with libraries of prewritten code. Along the way we learn about the importance of portable compilers and the interdependence of portable compilers and portable operating systems and libraries of prewritten code, and the importance of all of those to the persistence of data.
Then we study the evolution of C++ and figure out by ourselves why its inventor Bjarne Stroustroup [wikipedia.org] is a brilliant idiot. (Hint: it has to do with interface hiding).
We join the ACM and read and understand their Communications up until 1990 (anything after that is encumbered by patents). This takes a very long time.
And then we invent some stuff and every fool that just got his AOL account feels qualified to call us an idiot because we didn't do things the way he expected.
How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.
It is. You were right.
Repost, sorry. (Score:2, Insightful)
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.
Re: (Score:2)
You were right also. I do need more learning and experience - and I intend to enjoy every bit of it! I like learning and don't mind admitting that I need it.
An honest appreciation of ones abilities, when, and only when, coupled with an honest awareness of ones shortcomings puts one on the best road to overcoming them. In other words, 'Humility is the straightest path to Nobility.'
Re: (Score:2)
Re:Experience (Score:4, Interesting)
Actually I wonder if the code written on the Vic 20 is exactly the code that matters. Even if it was just copying right from Byte magazine.
Here's what it says to me:
This is a software developer that was doing computer stuff when he was young because he enjoyed it. Not IM, not games, not first person shooters or flight sims. Software development in its basest form. For free. Because he could.
It also says he has been doing it for a very long time. If he is still doing it, he does it because he enjoys it - not because of how much it pays or how glamorous it is or how 'easy' it is compared to other jobs.
There were plenty of kids with the opportunity to spend all day every day on the Vic 20, but very few did so because in all honesty from an 'entertainment' perspective it sucked.
Give me someone who grew up hacking on a Vic 20 any day over a coder who knows the Java API set inside out (but started coding it three years ago, and doesn't know anything else.)
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: (Score:2)
Mod parent up. Exactly what I wanted to say. K&R as the founding text of functional programming is just a bizarre idea.
Re: (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: (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).
Re: (Score:3, Insightful)
The problem is that that was not a shortcut.. it was a humongously wrong statement that shows you probably do not understand the concept you're mentioning.
Only if its the right experience Re:Experience (Score:3, Interesting)
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 C
Re:Experience (Score:5, Insightful)
I think the real issue is there is no 'routine' aspect to software.
Most other domains of Engineering have a very defined field and set rules. There are also very standard way of doing things. Simulators have been built...
I would argue that anytime some *new* device in another field of engineering is done, it suffers from the same 'flaws' as software. I can't speak for too many other fields, but I can speak for electrical engineering. Any new kind of hardware follows the same kind of iterative, simulate, debug... aspect as software. Fortunately, for hardware it needs to accomplish its set goal and people recognize the costs involved... and it somehow managed to escape the anyone can code mentality.
Now software, we must understand is be definition new. ANY repetitive work is done by the tools (compiler, linker...). In Civil Engineering, you still need the civil engineer to oversee the building of the structure. To make sure the workers do things correctly... this is all very routine work. Often there are standard blue prints already done and the civil engineer just makes some small tweaks and then has to oversee the project. Just follow the damn process. In software, we are so fortunate, that our builders (compiler, linker...) work amazingly well. They never make a mistake and can repeat their work as often as possible.
Once built, software can be deployed a million times over without fail. Not so for civil engineers who must pursue the same rigor each time a building is built.
Heck in software, we like to make one deployment so flexible by these amazing things called 'options'. everything is a bloody option and configurable. Again, unlike many other forms of engineering where the regularity and standard process dictates how things are done.
We must understand this key difference. Because of the nature of software, *some* people have made the mistake of trying to superimpose other disciplines onto software.
There are those who would say that software is design and implementation.
First you design it, like the civil engineer designs the building.
Then you implement it, like the workers build the building.
I cringe whenever I hear a similar analogy. Yes, there is some 'abstract' notion of design away from a specific language, but expressing that design in a particular language is still design.
The civil engineer who uses autocad or whatever to design their building is expressing his design in that format.
The software engineer is just expressing his design in C++/Java...
THERE IS NO IMPLEMENTATION WORK IN SOFTWARE.
Everything is design. Just high level design and low level design.
Sadly, some people continue to try and draw parallels with factory or civil engineering work. They claim there is some design that can be done, and then a bunch of code monkeys (construction workers) assemble and build the software. It's so wrong on so many levels, I'll repeat it again. The compiler and linker assemble and build the software. Every code monkey is doing design.
For sure, I think we will get *some* formalization of the process as certain practices become more standard. Our tools will most certainly become better and better (issue trackers, source control...). Yet at the end, the code still needs to be designed. There is no escaping the need for good software engineers.
Just like there is no escaping the need for good civil engineers if you every try and do something out of the ordinary.
I could write more about formal testing and the like, but I'll leave this point as is.
Is software "engineering" really engineering? (Score:4, Insightful)
Re: (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.
Re:Is software "engineering" really engineering? (Score:4, Interesting)
Re:Is software "engineering" really engineering? (Score:5, Insightful)
I'm not sure if I want to reply to AC's, but I forgot to mention I'm a structural engineer myself by education... Most structures of respectable size fall back on Finite Element Analysis to gauge the response to a variety of loads. [The estimation of loads is a research topic in itself, where the factors of safety comes from a rigorous stochastic-based reliability analysis].
Once analysis has been performed, design is a bit of intuition, but certainly not estimation - it's more of heuristics... so you say, "this worked last time, let me try this option and analyse if it'll work this time too."
So... A "real" engineer uses heuristics, common sense, estimation, and best of all, a complete unreliable piece of _software_ that was written by a programmer (who we just established can never be an engineer since they cannot be rigorous) to rigorously analyse his work? Looks to me like you are building your bridge on rather shaky grounds there, if you'll forgive the metaphore...
In the meantime, I found myself wondering how maintenance works for real structures. Apparently you _can_ rule out the human factor there completely, making "real" engineering thereby far more rigorous? Don't forget that "maintenance" means something very different for software than it does for real structures: you don't have to paint your software once every two years... What we call maintenance really is "changing the structure that is already there to become something else". I'd like to see someone add a lane or two to an existing bridge without involving humans at some point as a fundamental factor.
Re: (Score:3, Interesting)
I doubt real engineers would use a completely unreliable piece of software.
Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.
And in the real world, it will be exceedingly unlikely that the finite element analysis software will work fine for lots of different cases, but fail dangerously for your case even though it is not really ve
Re: (Score:3, Interesting)
"completely unreliable piece of _software_"
I doubt real engineers would use a completely unreliable piece of software.
The point of this article was that software engineers are not real engineers because they lack rigorous frameworks and rely too much on human factors. Seen from that point of view, you really only have two classes of software: those that are rigorously engineered to be reliable (and the article already claimed those don't exist), and those that are not. The last group must therefore comprise all software that's out there.
Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.
Fine, no problems with that. But "real engineers" should then also accept software engi
Re: (Score:2)
You're welcome. You mean there was an article? I didn't bother reading it.
Did I miss much?
Re: (Score:2)
> Thank you for disproving the article entirely on your own.
You're welcome. You mean there was an article? I didn't bother reading it.
Did I miss much? :)
Not really. Reading back, I see my posting reads a bit like a personal attack on you, but that really wasn't the intention and I apologize if it was perceived that way. I just get riled up at the whole "software engineers are not real engineers" thing; structural engineers are not infallible either.
Software projects do fail, at a rate that is too high, but in my opinion that is not caused by lacking engineering discipline but rather by ridiculously low deadlines and cowboy operators (even if they are wearin
Why many software projects fail (Score:4, Interesting)
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.
Re: (Score:2)
Ah. So that's how Steve Jobs projects his reality distortion field!
Re: (Score:2)
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:Is software "engineering" really engineering? (Score:5, Insightful)
For me, what delineates "engineer" is much better defined in my mind by "engineering type." While a software engineers, civil engineers, and mathematicians may vary quite a bit in average disposition, they are more similar than dissimilar compared to the rest of the population. I genuinely believe that there is a major difference between the engineering mind (or in my case, CS), and everyone else. Similar to how painters, composers, and photographers all may vary in general, yet they're more similar to each other than the rest of the population.
Re: (Score:3, Insightful)
Sorry, but Software Engineering houses most of its complexity in the actual complexity of the chosen language and Art of Design that has nothing to do with Traditional Engineering. I'll put it this way: Becoming proficient in C/C++/ObjC/Java is a matter of exposure to the language and various APIs with well-tested design patterns others have tested and shown to be useful, on a domain specific problem set.
Learning these languages is not remotely the same as learning Heat Transfer, Non-linear Dynamics, Quantu
Re: (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:Is software "engineering" really engineering? (Score:5, Interesting)
Soft skill? Depends how well it's done. Lets use car repairs as an example. There are many times I've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars' or a 'bush mechanic' and fixed in 15 minutes. Ie. Sometimes the ability to observe, sort information well and problem solve is worth a lot more than a piece of paper with 'engineer' written on it.
Another example. I run a computer repair business with a 'no fix, no fee' policy. Even though I've never had a single day of formal training in the field, I have never, ever had to bring that policy into action. Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.
Re:Is software "engineering" really engineering? (Score:4, Insightful)
Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.
Interesting post - I believe there are different kinds of thinking. I've had the benefit of learning how to fix cars by tinkering with them alongside my father since I was 10, and also a decent post-grad level education. I'm pretty good at fixing things, both cars and complex systems. I'm not special - there are plenty of people like me, including you, it would appear.
OK, some missed out on the practical stuff, and have thus never developed this 'practical' side. This does not make them incapable of thought IMHO. ;-)
For example, my wife is a lawyer - I'm amazed at her ability to spend hours 'thinking' about a complex case and then having that 'Eureka' moment when she finds the angle that she'll use for constructing a defense or attack. She's not worried about not knowing how to fix her PC or her car - she has a husband for that
Re: (Score:2)
Re: (Score:2)
I'm being honest here, what's the difference?
Re:Is software "engineering" really engineering? (Score:5, Interesting)
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?
That's just horsepucky.
The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to, say, 3" C-Channel girders. But just today, I was doing some engineering to develop a distributed, self-healing clustering file system. Specifically, I was doing performance analysis of different approach, doing a base unit of 1,000 simple file reads. That is most *definitely* a physical analysis - performance tuning always is. But do I care about each individual line? Not really. Do I do extensive analysis of each individual element? Not by a long shot, simply because the actual, real, overall cost of the software is so low.
We host highly complex, vertical-market database solutions. We have a pretty decent hardware cluster comprising some $25,000 in whitebox rackmount equipment. A nice half-rack of stuff. And another $10k or so for a failover DR scenario. But compared to the number of customers we service, and the size of my company, that's an insignificant investment, yet we are overbuilt at least 400%!
If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?
Not engineering, but it SHOULD be (Score:2)
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 yo
Re: (Score:3, Insightful)
If a student can't learn the basics of computer programming as part of a four-year program (whether CS, CE, or SE), perhaps programming isn't the field for him.
Unfortunately in this imperfect world, there's few such research positions available. But they aren't
Re: (Score:2)
Software Engineering is really Design (Score:3, Insightful)
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
Thank you, Captain Obvious! (Score:2, Insightful)
Humans are not maths.
Software Engineering is trying (Score:5, Insightful)
.. 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.
Re:Software Engineering is trying (Score:4, Insightful)
.. 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.
As a senior in a software engineering major, I tend to agree. While there are any number of methods, design tools/patterns, and whatnot to help me do my job, in the end it is my own ideas and styles that define the product. There's certainly an element of artistry to it - a small block of recursion that accomplishes something horribly complex is just... beautiful.
Another thing that contributes to its non-rigor is the domain knowledge requirement. I can't effectively build a system unless I understand (at least at a high level) how it works. Each industry has its own specialties and levels of difficulty, and you can't teach all of that in school, so they teach us how to think and learn instead. They give us ways of understanding the problems we need to solve, and that's really what we do - solve problems.
Re: (Score:3, Insightful)
This reminds me of a fairly large OSS project where they were recursively doing SQL queries after certain actions to clean up. This worked, however they didn't take into account scalability.
The project I was using this for was about a factor 10 larger than usual and it became terribly slow. The database was being pummeled recursively with SQL queries and the whole thi
Re: (Score:2)
>.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be.
"Real Engineering" has something called "Strength of Materials". You can build a bridge out of wood or out of steel, but the designs will be different because engineers are aware that different materials have different properties and have some ability to quantify those differences. Designing a bridge so that it will "scale" would never be attempted in any real engineering discipline. However
Re: (Score:2)
My first CS professor told me that there are nearly infinite ways to accomplish any single task on a computer. He felt this meant computer science and software engineering were arts...
"But we don't call them art because we like paychecks."
Wicked Problem (Score:2)
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 problem
Chuck Connel does not understand Simon's work (Score:4, Interesting)
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 [wikipedia.org] built a solid framework for understanding human decision making process. This framework is just as solid as mathematical formulas behind computer science.
Software Development is actually an art (Score:5, Insightful)
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.
Like Architecture (Score:3, Interesting)
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).
Re: (Score:3, Insightful)
Except architecture is a highly regulated and licensed profession, whereas any schmuck can write code.
Re: (Score:2)
Sure but that was n't my point, my point was multiple outcomes from the same specification.
Any schmuck writing code is like me getting a copy of AutoCad and drawing up a floor plan. Besides, I've seen many badly designed buildings so being regulated and licensed does n't guarentee good building, it just limits (but does n't eliminate) the possibility of buildings collapsing.
Re: (Score:2)
I realize that was not your main point.
When collaspes happen, if the architect or engineer (or firm) is responsible, there is a venue for a professional misconduct hearing, leading to the loss of license.
Re: (Score:2)
Re: (Score:2)
If an engineer designs a car and it crashes due to easily-avoidable defects, he goes to jail.
[citation needed]
Re: (Score:2)
No. If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court. If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible". So, the first engineer's company gives him the money, means and time required to avoid those defects. The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'
Re:Software Development is actually an art (Score:4, Insightful)
I agree with the sentiment, but in a business context, I think that means we're doing it wrong.
Production software *should* be boring, and rigorous... and correct. Now, I know this has all been hashed out before, and it's one reason why we ended up with Agile methodologies, but very very very little of what we do needs to be clever, or innovative. Despite what we think, most of us aren't smart enough to build clever AND reliable software, so we end up crafting things rather than truly engineering them. Those of us who ARE smart enough probably aren't working on projects with enough budget to take the time to do so.
Old debate (Score:3, Interesting)
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.
Compare and contrast Comp Sci & Comp Eng (Score:2, Funny)
Engineering != Science (Score:3, Interesting)
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.
!(Science != Empirical) (Score:2)
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 i
Overlapping disciplines (Score:2)
The difference between Engineering and Development (Score:3, Insightful)
...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.
Elitist crap (Score:3, Insightful)
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.
well, duh (Score:3, Insightful)
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.
Not just software (Score:3, Insightful)
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.
Didn't carmack comment on this a few years back? (Score:2)
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 [fogcreek.com]
Fashion versus maths (Score:2, Insightful)
Software Engineering = fashion
Computer Science = maths
Simple. Nuff said.
Involves humans, eh? (Score:2)
Software engineers can get jobs (Score:3, Insightful)
Computer Science != Coding (Score:2)
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 distin
Re: (Score:2)
Clap, clap.
Wow, you know everything. And not even finished yet.
Do you realise how stupid you sound? I've been a practitioner of comp. science for 10 years and have never heard so much tripe before in my life.
Software never fails, people decide it does (Score:2, Interesting)
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 si
Feedback loops accepted (Score:2)
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 dat
Misleading Title (Score:2)
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 l
Professional Engineer (Score:4, Insightful)
Re: (Score:2)
The usage varies by country. In America an engineer or technician refers to a profession, in some parts of Europe it refers to a degree.
But then I'm not an engineer by any definition.
Re: (Score:2)
Quite possible, but I know in some countries you are granted an Engineer's Degree instead of a Ph. D. for analogous work in an engineering discipline.
Then again, my US school (Caltech) mentions that some date is the "last day to defend your dissertation [for this year] for the degress of Doctor of Science and Engineer". So maybe it's here as well, I don't actually know.
Semantics, semantics
Re: (Score:2)
Professional Engineer (PE) needs a license. The rules vary from state to state, with all requiring you to pass the NCEES Principles and Practice Exam for your chosen field.
http://www.ncees.org/exams/professional [ncees.org]
Before we get all sweaty about terms (Score:5, Funny)
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.
Re: (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: (Score:2)
In fact I'd say it's hard to design an autonomous system that can keep killing people despite everyone else trying to stop it.
Y'know like one of those killer robots from the future.
Re: (Score:2)
That's only half of it. You need to design it so when used within specs it reliably works, but when used outside specs (by some margin X) it fails. As the saying goes, any fool can build a bridge that will stand, but it takes an engineer to build one which will just barely stand.
Re:Before we get all sweaty about terms (Score:4, Insightful)
What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life. Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.
Re: (Score:2)
This is what the previous poster wanted to say.
Technicians = {(X,Y) | \forall X \in Company \wedge \forall Y \in Company-Technology}
However, a technician is a person who comprises a subset Technicians, were the subset is bigger then 10. The rest are bad paid personnels which is laid of at the first sign of trouble. I say that not out of disrespect for technicians, it is just the way how things are. You are not an engineer when you know certain technologies. An engineer needs to know the basic concepts behin
Re: (Score:2)
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.
There's a difference between a programmer and a software engineer. Just like being able to nail pieces of wood together doesn't make you an architect, being able to write out a piece of code that does what someone else told you it has to do does not magically grant you the ability to design large or complex software systems.
Re:You're not Engineers. Get over it. (Score:4, Insightful)
Nothing magically grants you "the ability to design large or complex software systems", no matter what degree or title you have.
All this discussion about Computer Science vs. Software Engineering vs. Programming is really about ego and will not lead to any improvement in any discipline.
Re:You're not Engineers. Get over it. (Score:4, Insightful)
If you're going to insist on rigorous naming, you ought to be consistent about it. Programming != "the IT crowd". There's some overlap, but there's a lot more programmers not in "the IT crowd" and a lot more to be done than programming within the "IT crowd".
Furthermore, I don't care how many bridges, buildings, or aircraft you can design, if you can't drive a steam locomotive (with attached train), you ain't no engineer.
Re: (Score:2)
> No engineering degree = no engineer
Look... I don't really care if I'm qualified to drive a train or not.
I create complex things that live inside the computer, using the constraints and software parts available, much like an engineer in the physical world works with constraints and existing parts to make something useful. Unless you want to narrowly define engineering as designing physical things, I don't see your point. Truth be told, I don't spend a lot of time worrying about semantics and titles -
Re: (Score:2)
Nope... nice degree, but the degree must say engineering too..
and Engineers still dont consider software engineering to be engineering.
And this from someone who nearly has that exact plaque on my wall.
Storm
Re: (Score:2)
'Wouldn't it still be as much a science as say... human psychology?'
Pretty much:
'...and this area is maddeningly slippery. No concept is precisely defined. Results are qualified with "usually" or "in general". Today's research may, or may not, help tomorrow's work. New approaches often overturn earlier methods, with the new approaches burning brightly for a while and then falling out of fashion as their limitations emerge.'
Re: (Score:2)
The article (unlike the summary) considers software engineering a part of computer science. But software engineering is quite a bit different from other kinds of engineering, and computer science isn't quite the same as physics either.
Re: (Score:2)
Maybe someday they will figure it out Abstradtion Physics [abstractionphysics.net] But I suspect that it won't be untill they stop making money from doing it wrong.... intentionally....