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."
.. 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.
In this case, "Physical analysis" would be running tests, deployment, crash analysis, etc. If we're comparing software engineering to "real" engineering, I feel it would be disingenuous to knock down software engineering because it works with code instead of physical items. The complexity is still there.
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.
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.
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"?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
All hope abandon ye who enter here.
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.
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.