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