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."
How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.
sudo mount --milk --sugar
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.
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.
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.
Don't we all need more experience?
The basics are pretty simple. And by the basics, I mean where Niklaus Wirth got his ideas for the mathematical basis for algorithms, Alan Turing.
Then we learn about functional programming from the guys who invented it: Kernighan and Ritchie. 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 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.
Help stamp out iliturcy.
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'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.
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.
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.
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.
Software Engineering = fashion
Computer Science = maths
Simple. Nuff said.
Zen tips: Pay attention. Don't take it personally. Believe nothing.
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.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
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.
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.
I want to play Free Market with a drowning Libertarian.
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.
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
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.
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.
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.
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 nonexistent. (as far as I'm concerned, you can have them, I prefer to get my hands dirty with code :-) )
Different kind of law. Moore's law is more like Murphy's than Newton's.
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.
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.
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.)
Glonoinha the MebiByte Slayer
"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).
factor 966971: 966971